Glob patterns

🦋 Proposals
1

Proposal: https://github.com/tc39/proposal-glob

I want to propose Glob to match glob patterns. The idea is to have the same API of RegExp:

const path = 'example/file.js'
const glob = new Glob('**/*.js')

console.log(glob.test(path)) // true

This will be useful for many JS libs that provide their configuration in Glob because is easier to read than regex. Right now all these libs have to do all the conversions from glob to regex adding extra size in their bundles.

There are a lot of languages that support Glob natively, however, JavaScript is not one of them.

1 Like
2

That repo link is a 404.

JS has no concept of “file”, and browsers don’t have access to the file system. This might be a better proposal for node?

2 Likes
3

It will be interesting to also have in the browser (IMO). For example for a router to manage the pathnames. It is just a string matcher, so it does not require any access to the file system.

About the repo, sorry, I got confused about how to create the proposal. I'm going to try it again.

4

Globs are isomorphic to regexps. The star and globstar patterns are not that hard to translate to actual RegExps (and many routers do exactly that or a variation thereof under the hood).

I'll give it to you, they come optionally with extensions that are less trivial to polyfill, but once again, I don't know how useful they would be in practice vs plain RegExps.

What more, on the server, going through every file in a tree and doing a pattern.test(fullPath) is not at all the most efficient way to proceed.

Suppose you want to match ./foo/bar/**/baz/*.js, you'll first want to limit your search to ./foo/bar/, then look for directories that contain a bar subdirectory, and only then loof for *.js files.

A lib that translates strings with ** and * to actual RegExp, without supporting [] and {} patterns would take a few hundreds of bytes, and there are probably several out there already...

Edit: case in point, after minification, https://github.com/fitzgen/glob-to-regexp is 760 bytes long, ~440 after gzip compression. OTOH, that lib has 5.5M weekly downloads, so there is demand for such a functionality.

5

In my opinion the bundle size matters most when it is sent across the wire and needs to be downloaded by a client; do you see a common need for globbing on the client side?

Maybe this would be better suited for server side (node or dino proposal) as they interface more with the file system.

6

Agreed - this is very much a host-dependent concern.

  • Runtimes like Node and Deno that run on the server, CLI, and desktop and regularly need complex file access have immense use for this.
  • Runtimes like Chromium and Gecko that run in browsers have precisely zero use for this unless they specifically use the FileSystem API (which is fleetingly rare outside Chromebook apps).
  • Runtimes like Moddable and Tessel that run on embedded devices have virtually zero use case - files are almost always explicitly known in advance, are relatively few in number, and you generally have to keep close tabs on their existence, location, and size.
7

Routing has different concerns, and in general is somewhat an unsolved problem in JS. Every framework does things slightly differently and has a different syntax for routes. In addition, you have other concerns to pay attention to:

  • For maximum performance, regexps are horrible. Instead of doing a single complicated tree search, you're doing effectively the same amount of work for each route. For large servers with many routes, this could start occupying noticeable amounts of request time - if you have 200 routes, each 30 characters long, every 404 could involve thousands of character checks depending on the URL. (And real-world backends for medium-to-large CRUD apps can easily approach 200+ routes in practice, trust me.)
  • Routes can be parameterized, and yes, this does complicate route resolution.
  • The list of routes rarely change, but they can change over time.
  • Route resolving and route templating, while implementation-wise are distinct, are conceptually intertwined and most will want a shared implementation of both. Also, redirects will pull facets of both templating and resolving, and are a very good example of a point of intersection between the two.

To summarize all this, routes are a completely different beast from globs and even regexps, and share very little in common once you get past the surface.