Allow globs in `entrypoints` field
BendingBender opened this issue · comments
In our project we have many entrypoints which are then compiled to a single JS. To manage the many entrypoints, we have a naming convention for the entry point modules, thus we never have to manually adapt the various configuration files in the project to pick up a new entrypoint.
It would be very helpful if elm-tooling.json would support globs in paths for the entrypoint field, thus we would never have to manually adapt this file, too.
As a workaround, we re-generate this file on each commit via a commit hook but it would be great to not have to do this kind of hacks.
Hi! A few questions to get started:
- How many entrypoints do you have currently?
- How often do you add new entrypoints?
- How often do you remove entrypoints?
- How do you create a new entrypoint – just create a new blank file, or do you have some script or template or something?
- What would happens if you forget to add one entrypoint (and you didn’t have the commit hook) – the Elm language server wouldn’t work as nicely?
How many entrypoints do you have currently?
25
How often do you add new entrypoints?
1-2x/month
How often do you remove entrypoints?
1-5x/year
How do you create a new entrypoint?
Usually we copy over one of the other entrypoints.
What would happens if you forget to add one entrypoint (and you didn’t have the commit hook) – the Elm language server wouldn’t work as nicely?
Yes, it's only about Elm-LS at the moment.
I talked to some folks on Discord about this, and the consensus was that this would put a big burden on any other tools (like editor plugins) that want to read the elm-tooling.json – any tool that wants to consume "entrypoints" now needs to be able to resolve globs. And we need to standardize exactly what kind of globs are allowed etc.
For the few projects that need to automate filling in entrypoints, a scripting solution is fine. It is a rather simple script, right?
That's a pity, I'd never expected that glob pattern resolution would be a big maintenance burden. I thought that it isn't that difficult to agree on a minimal glob pattern variant. Most config files I know of support this scheme of defining files (tsconfig.json, package.json, .*ignore, .eslintrc, ...).
What glob features do you need for your particular use case? Can you show what your "entrypoints" would look like as globs?
The glob pattern we use is: ./src/App/**/Main.elm. I expect the * and ** to be the most widely used glob patterns. There are of course many more patterns provided most libs that I know, one of the most prominent libs for glob patterns in node is https://github.com/isaacs/node-glob, which is the lib that we use to generate our elm-tooling.json.
Actually, I've just improved our pattern a bit for it to not traverse directories unnecessarily, here's the new version: ./src/App/{*,*/*}/Main.elm. But it's just a minor improvement, the previous pattern would be more than sufficient for our use case.
I think just supporting the same patterns as in a .gitignore file would cover most use cases. This boils down to the following patterns: *, **, [], ? (see https://git-scm.com/docs/gitignore).
You might be interested in this PR: elm-tooling/elm-language-server#629
It removes the need for "entrypoints" at all.
elm-tooling/elm-language-server#629 has been merged, so "entrypoints" isn’t needed anymore. I’ve also removed "entrypoints" from this repo: #77. Closing.