-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make Javascript imports consistent #1919
Comments
More consistency is definitely desirable. I want to move to an import-map solution, mostly because this will make it easier/possible for external plugins (hosted anywhere) to import stuff from Fontra (core/web-components). We could then manage the (JS) cache busting stuff by just manipulating the import map. (I don't think import maps work beyond JS source files, which is a bit of a bummer. Fontra's cache busting scheme works for most assets, not just JS.) |
Not sure, my version of Node is too new for Fontra. ;-)
|
Ugh, they made "assert" a reserved word, just like that? Or is ES on board with this? |
That's not the problem, the problem is that the import assertions syntax - which was an ES proposal - has developed into a more generic "import attributes" syntax. It's still a proposal (stage 4) but people are using the new syntax. |
Ahh, then it's this: fontra/test-js/test-classes.js Line 5 in 1d343fb
It needs to be replaced with something more contemporary then. |
|
No, this is a nightmare. Having the browser resolve the imports with an importmap means they don't go through the cache-buster. In some cases (e.g. |
We can replace the (JS) cache busting with a cache busting import map. I have indeed found in the past that using an import map does not work well with the (current) cache buster. While I'd love to improve support for bundlers, I don't want to depend on one. Some of the things to do I posted here should make things easier. Esp. to make the "views" be part of the proper assets tree on disk, instead relying on server juggling. Then we could switch to all relative imports. |
Ah, I presumed that the idea of views being pluggable (and defined in the pyproject.toml) is to allow people to add their own out-of-tree views directories which then get overlaid on top of the server web root. If we're content to just serve a static assets directory then the architecture gets much simpler (you don't even need to "register" views as entry points, they're just more files to serve) ... but we lose that pluggability. |
The idea is that the builtin views become integrated (and indeed don't need to be registered), but that views are still pluggable with the existing mechanism. So any plugins made that way would be more tightly coupled to the server implementation. |
So it looks like there are a lot of constraints we want to fulfil here:
I feel like some of these constraints fight against the standard ways of doing things in JS web apps, but you're entitled to make those architectural decisions. The upshot, though, is that I just don't see a solution which fulfils all of these. |
The first two should be able to co-exist when using all relative paths. There third (layering on external out-of-tree views) seems the most problematic. I'd think these could still use absolute imports (and then depend on a more restircted type of deplyment). But since we don't have an actual example of such a plugin (ignoring the current built-in views), perhaps I should for now let go of this idea. |
I think if you're prepared to rethink one of your constraints, I'd highly, highly recommend you to rethink the opposition to requiring a bundler. It is just the way that JS applications are developed these days, and for good reason; it would have various advantages for Fontra:
I don't quite understand the reasons for your opposition to requiring a bundler - but I do note that in practice, you require a bundler already for I'm prepared to put together a branch to demonstrate this if it would help you evaluate it. |
I'm not opposed to maybe requiring a bundler for deplyment. But while developing, I tweak some CSS or JS, do a reload in the browser and I see the result. This is incredibly convenient while developing, and I'd hate to lose that instant dev cycle. |
While working on FontraWeb, I have
running in another terminal, and I get that instant dev cycle. We can wrap that up as |
How long does the build take? |
|
Not bad. Yet, it adds complexity to my dev experience, and when we fix the import inconsistencies and the out-of-tree views, I really don't see why we can't have both. |
Ah well. |
There are three kinds of Javascript import: relative (
import { Foo } from "./foo.js"
, often used by people who bundle their imports into a single deliverable); root-relative (import { Foo } from "/foo.js"
, often used by people who deploy everything on the web) and the ES2020 absolute (import { foo } from "foo.js"
).Currently Fontra uses an inconsistent mix of relative and root-relative:
Inconsistency is confusing in itself, because it makes developers question why one thing is one way and another thing is another, but as you can see from the screenshot, this also confuses code analysis tools.
Root-relative imports confuse them because
/core/var-glyph.js
is interpreted as an absolute filesystem path, which is manifestly not true; but this can be worked around potentially by tweaking an import map. And relative imports confuse them similarly because the import is just not correct from a filesystem point of view: in this example,src/fontra/views/editor/edit-tools-pointer.js
includes../core/vector.js
, which you would think meanssrc/fontra/views/core/vector.js
but is intended to meansrc/fontra/core/vector.js
! (And code analysis tools are helpful because, as you can see above, they're good at finding unused imports!)I propose that
core
(andweb-components
) imports become ES2020 absolute imports:I have this working locally and can make a PR if the idea is agreed.
The text was updated successfully, but these errors were encountered: