Current Roadmap #17475
Comments
|
To begin with, I'm not trying to be rude or something like that. Maybe my English is not fluent enough. But yes, the following questions are very important to me personally and a few people I know in person.
|
This comment was marked as outdated.
This comment was marked as outdated.
|
Second impression, after some time waiting for my impression to settle: Most of these changes are starting to make sense to me. I understand that many people have ideological concerns with this one and I still believe that there are more important things to work out but at a fundamental level, most of these make sense to me. Some people are treating this as if it were a random list of ideas but I'm sure deno core has done a lot of discussion internally on these. The one thing that I absolutely have questions on are
How? Will deno specifiers only work for modules that are using semver themselves? This sounds like a massive pain to deal with code-wise but I think it's still useful to clarify what what this means. Edit 2: Looks like this isn't nailed down yet.
The "by default" in this line is tripping me up. I guess that this implies that other registries will be supported (which I am a big fan of), but the question of how? comes up again.
Not quite sure how this will work in relation to semver, but this SGTM. If I specify
I don't know what this means, please clarify?
Cool for extendability, I like this one.
Are these in order of resolution? Like, will Also, doesn't this kind of reinforce the idea that Edit: @crowlKats has clarified some stuff on discord. Do not quote him on this one, I assume it's all tentative, just writing this for others to hear
|
It menas that /x/ would resolve imports that use specifiers defined in an importmap, so a module that uses import maps would be possible to be imported and used properly
We already mention convetion of mod.ts in the manual, and the registry already has similar resolution for the doc view. |
|
A few more thoughts on
It feels not OK to do it magically during a publication on /x/. I understand the idea, but it feels more natural to say that import maps are just not suitable for libraries and suggest users a few options:
At first sight, I see two options :
What happened to this rule? Again, this is going to break many ideological decisions that made Deno beautiful. We simply don't need it, since it's OK to write Again, Deno replicates browser behaviour in many ways, Deno uses import maps because of browser. Obviously, browsers won't support Deno core team said for multiple times that version-resolution problem should be solved in user-space. Aren't you believe in it anymore? If core team wants to handle versions, it might intoduce another user-space (again, denoland-repo related possibly) tool. Let's say, you have multiple modules with specific dependency URLs. You can just walk through the tree of dependencies and remap them accordingly to semver rules via generating an import map (and possibly merging it with user-defined one). Interestingly, one'll need to parse each URL slightly differently based on particular CDN URL pattern, but it still might be configurable and not bound to deno.land/x/. That being said, the PoC worked for me pretty well. One might say that there is other problem than bundle or runtime — type checks. Personally, I would prefer to ignore this "problem", because I've never encountered unsolvable type problems between dependencies during development for Deno. What I'm trying to say, is that it's not quite clear what problem is unsolvable without |
|
I'll try to answer some of your questions now, as we are still working on the roadmap:
It is team's thinking that it would be more handy - I'm myself not a fan of this solution - I would prefer if import map was embedded under
Main point is that we need to provide semver resolution, that we were unable to figure out with http/https imports. We are still thinking about other names and providing a way for other registries to register their own prefix.
If you'll have an entry in an import map that specifies
There's
Some frameworks/build tools from npm still produce CommonJS output (eg.
This was removed from the roadmap for now.
That's true, but the fact is many frameworks from npm assume that there will be local EDIT: Questions from other comment
That could happen locally via a CLI.
The registry would be open source and users would be free to host their own instances. Still these are all additive changes. You will be able to use existing http/https imports just fine if you don't like this solution.
It's not set in stone that this redirect will happen. It's a current roadmap, but we'll be evaluating all these points as they are about to be implemented.
It's not another standard, all of this is based on import maps standard. Since import maps are not composable we need to find another way to make it easier for users to create "a collection of ES modules" which is essentially a library or package (offtopic: it's been growing on me and I think it's a missing bit in ES modules standard that could have saved the community a whole lot of headaches if it had been defined). |
|
Same deal here:
I'm not sure sure I understand the question. AFAIK no registry validates if a package follows semver (ie. ensures there are no breaking change in patch and minor releases). It's up to the library author.
We are looking at making the protocol for registry public so that other registries can implement it and allow users to register their own prefixes with the runtime.
Libraries in the registry could use bare specifiers and have an import map. During publishing step the processing would be applied that replaces bare specifiers with relevant entries from the import map.
This needs to specified further. I believe it would be a setting on the registry (effectively it would be a redirect - you configure you library in registry to redirect to module |
Ah sorry, I should have been more clear. My question was regarding how you would deal with libraries that aren't versioned using semver. A lot of libraries use something like calver or literally just update names.
This sounds good to me but yet again this feels not very well defined.
I need to think about this one to really determine how I feel about it. Definitely mixed feelings on this one. On one hand, it would be really convenient, on the other hand I share the concerns of @albnnc.
As far as I can tell, the registry current has no settings page for the module authors to interact with. In my view, this is a good thing (opinionated > non-opinionated). I agree that this does need to be specified further. |
|
I agree with the following suggestions to improve compatibility with Node.js.
However, I don't feel the need to introduce the following behavior, which is incompatible with both Node.js and browsers.
The Deno-specific module resolution with Updating a version-pinned module is a bit of a pain at the moment. However, I think that it should not be solved by introducing semver, but by officially providing automatic update tools such as deno-udd and dependabot. |
|
Thank you for the reply, I appreciate this.
importMap.imports would be great indeed, but it is, likely, a matter of taste. It should be kinda OK, since nobody is forced to use this feature.
I will try to ask some concrete questions about this at the end of this comment.
My idea is that Deno, probably, should be searching for
Use-case: the team wants to forbid the usage of This feels a little off-topic. If this idea is adequate, I can submit a separate feature request.
Yes, for now, Next.js producing legacy CJS. Yes, for someone it would be better to just wait for Next.js to drop CJS support or to just not use Next.js at all. Supporting all (possibly legacy) frameworks have nothing in common with building elegant and stable platform. Why would anyone even try to build something like fresh or Aleph.js if Next.js worked perfectly? The really bad thing about it is that not only fresh / aleph projects are going to be disadvantaged, but we will less reasons for deno.json usage, since package.json is going to be more universal. This idea is somewhat acceptable, but it seems very strange to implement it if "no one's happy about it". Maybe it's better to just don't support Next.js officially.
Thanks for cautiousness and interesting links. I think that the reasoning for ESLint looks more clear now.
Although the integration of
That's good, but it looks really similar to NPM. How many other NPM registries are popular?
This is only partially true, probably. Yes, we'll be able to use raw URLs. But once semver-resolution becomes popular enough, it would be impossible. I mean, how would one use a library with
Thanks for that. Please, continue to use GitHub for that too, since sometimes it's almost impossible to track Discord. GitHub is very good for history also.
I tend to disagree. To begin with, I think that ESM spec is OK, because it defines how modules are written and combined and not how registries (or collections) are built. The good part of it is that it's simple. What I don't understand, is how the proposed idea completely based on import maps spec. Yes, you can say that module-resolution involves magical internal import map generation. But it's really controversial, since this process will probably be hidden, unclear, while import maps supposed to be application level and mostly unchangeable. Moreover, user-defined import maps should be taken into account during this process somehow. The most abnormal part (which is really hard to accept) of it is that the result isn't completely determined and depends on the current state of registry index. Analysing this further, it looks like
Again, some of us just don't see any need for the support of Talking about Yes, you might think that we need to support some sort of |
|
Regarding import maps:
Please don't add anything like a build step. I love that I can write a source file, publish it anywhere, and run it again via its URL. I love even more that this is the only way and it's the right way. It's so straightforward and dead simple. As soon as you start introducing weird features that mess around with the source files at any point along this chain, you're breaking this trust. I could then no longer be sure about what I publish and what people run (unless I understand the internals of import maps and make sure it doesn't affect me). This means
I share the hesitation for some of these features. Yes, we really need a way to do semver and remote module deduplication, but please let's not rush this, keep up the communication with us, and let's build the right system. It would be a shame to repeat the mistakes of Node. |
|
We should break this issue up into multiple issues so the conversation is focused on each point.
@albnnc they can via an import map. It will be trivial to generate an import map from the output of
The key here is that these semvered specifiers provide a way for module authors to publish the constraints of their dependencies rather than exact versions. Module authors usually have the best knowledge of what semver range of their dependencies work well with their module instead of module consumers. Another important part is that Deno will automatically handle this so users don't need to worry about creating an import map themselves--when Deno reads semvered specifiers in loaded code, it will create an implicit import map that Deno handles for the end users out of the box. We could ask people to try following a convention for this and then manually generate an import map, but this is not a great experience.
@KnorpelSenf You will still be able to do this. This is an optional build registry only (non-CLI change) build step for people who want to use bare specifiers while authoring modules. |
That would be nice.
This exact line is about Obviously, one will be able to make browser resolve I wrote a little more about
Good point, but the counterarguments are the following:
That tooling might, for example, treat
I agree and this is what @KnorpelSenf was writing about. Build steps aren't good, but I still think that they're still better than registry magic. That being said, I think that our common point is that Deno doesn't need semver-based module-resolution logic at all. |
|
I feel strange that |
I'm aware that this won't break existing functionality. I just disagree that it's a good idea to provide a second and less explicit way to do the same thing, just because it looks cute. |
It's already technically possible for people to do this. We will just be providing an easier way to do it. Also, IMO using import maps isn't something that is functionally reduced down to "looks cute". Import maps provide a way to map bare specifiers to all your dependencies stored in a single file. |
I agree, could you split it up and link to the created issues here? :)
Right, my bad, the part that's useless and looks cute is being able to drop |
|
Pre-warning: I disagree with adding Pulling in two directionsThe first issue I see is that plain The first promises to make importing from the /x/ registry a bit easier, while also providing semver support that Deno can then use to deduplicate dependencies in the same vein as NPM and Deno's NPM support do. The ease of importing, while cute, doesn't seem to be that big of a deal: Saving the keystrokes between Semver support is an added feature that, as @dsherret mentions, can already be done either manually or by an external tool. Achieving deduplication with this feature requires that all of your (deep) dependencies also use semver imports, however. (See below for more discussion on common usage.) The second promises to make authoring libraries with import maps easier. Fair enough, but unfurling an import map means that eg. a Common usageNPM achieves deduplication of dependencies through a common usage of the registry with common (though occasionally misused or broken) semver based package version naming. Each package will declare its dependencies with the same semver format, and thus deduplication becomes possible. The /x/ registry does not do this, and the obvious intention seems to be that this would not be forced, or even necessarily recommended. Import maps unfurling would even do the exact opposite of this. As a result, if you wanted to see your /x/ imports deduplicated, you'd need to use only such modules (or are they now libraries?) on /x/ that use semver. Conversely, if you wanted to only use static version imports you'd need to select your dependencies in such a way as to only use statically importing dependencies. This is an issue on NPM as well, where I believe the usual choice is to include deep dependencies as your own dependencies to force the version. With Deno the answer would of course be to manually import-map these dependencies. For semver deduplication, any library you import that uses static imports would always cause a duplication to occur. For example, you import Counter point: Why wouldn't Deno just notice that Alib is already imported with version I ran out of time so I'll come write some more later. P.S. I support going all-in on NPM for semver stuff. Deno has already spent good hours supporting NPM, why not lean in on that? Is there truly a need to make /x/ be a big thing, competing with NPM? Can /x/ not be its own, opinionated registry for those of us who'd rather not have all the extra? |
|
Continuing from the previous: Playing to your strengthsAs I mentioned in the afterword of my first comment, I have not really understood the intended benefits of adding further automation and features to /x/, specifically as it comes to semver. I can kind of understand new users not liking automatic NPM has great strengths in its wide usage, it's audit tooling, and it's automatic semver based deduplication. Deno supports NPM now, so it seems wise to me to utilise this strength and lean into it instead of trying to reinvent it. The /x/ registry has its own strengths: It's simplicity and the independence of runtime brought about by that (excepting runtime specific API usage which one cannot really guard against, as we see with Node only modules being published there). It's intentional lack of metadata to eg. guide users by engine / runtime, by peer dependency etc. can be viewed as a fault but it is also very much a choice made by the registry, presumably with full knowledge of what it will mean. In trying to change /x/ to be more like NPM the Deno team seems to be playing to the weaknesses of the registry, and fighting against the strengths of NPM. Given that NPM even explicitly invites non-Node code through its Make publishing Deno libraries into NPM easy and convenient, and keep on improving the NPM support. Keep the /x/ registry as a simple, opinionated registry with static version dependencies. If in the future the userland or ECMA spec proceeds to a direction where library imports and semver become possible then take that step there, with the spec instead of with magics built into the runtime. There already exists some work to this end with Web Bundles. As said in the beginning, I don't understand what the intended benefit of adding semver into /x/ is. If it is for more registry usage then why? I doubt there's a financial benefit. If it is for Deno usage then I expect NPM is a stronger route to that. For Deno Deploy as well I expect getting further NPM support has a better return on investment than adding another NPM contender. Binding Deno strongly to /x/ in addition to the already existing NPM binding seem like it would only add more complexity to both the runtime binary and the registry, neither of which really needs it as NPM support already does it all in a better way with a bigger addressable market. |
Couldn't Deno just as well handle this automatically in such a way that the /x/ registry would send in its responses a special header if a particular published module was contained in a library where an import map was present. Deno could then automatically download said import map (header contains URL or relative path) and include it as a scoped map in the users (implied) import map. A CLI command could be used to create a complete import map this way, with possibly automatic helpers for user-based deduplication. The best part here would be that this would not tie Deno with /x/ at all, as any other registry could pretty trivially include the same header in their response to get the same effect. It would also work as a relatively neat halfway point between NPM-like automatic semver deduplication, and /x/'s strict static imports: By default scoped import maps would retain the static nature of the imports but either manual manipulation or automatic helpers could be used to do deduplication when and where it seems possible. Given the free-form nature of /x/ publishing it seems like semver-deduplication would need to be best-effort anyway, as eg. EDIT: There's an issue I didn't really consider here properly: Automatic joining of import maps is not yet defined in spec (a proposal exists but it's not yet fully decided on) and thus including the algorithm in Deno would risk possible future breaking changes. If the automatic joining was only provided as a CLI command or script instead, ie. "generate an import map that joins my current dependencies' import maps" then future breaking changes could be avoided: Any import map created today would still work in the future, even if the specific composition algorithm changed that Deno uses to create these import maps changed in between. |
|
When taking a step back, Deno really just runs the ES modules that work on the web. Any problem related to dependencies will appear both for Deno modules and for ES modules on the web. Consequently, we should use/invent a web standard for this. What would the ECMA spec say about semantic versioning and dependency deduplication? |
|
Is this issue planned to be fixed in Q1? |
Thanks for doing this! There are now:
|
@Kycermann Yes, it's covered by #17264 |
ECMA spec doesn't really consider dependencies or libraries, and semantic versioning to be part of it's cup of tea. The closest we get to libraries is probably with Web Bundles (https://github.com/WICG/webpackage) and bundle preloading (https://github.com/WICG/bundle-preloading), but there too the answer is pretty much just a lock file -like "is this the same file I got last time" type of checking. Browsers really do not have the "time" to ponder such things as a dependency graph and its possible deduplications. The only tools for the job, really, are the import map or a ServiceWorker since either of those can be used to reroute imports to another location. I think that's also the only thing ECMA or WICG will ever give us. WinterCG might change that though. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
Feels like it's become another nodejs |
|
We're way past Q1 2023 now, soon into Q3. Is another roadmap coming? |
|
#18836 provides some insight already |
|
Right, but of two issues that are pinned to the repo, one is for Q1 2023, one is for the month of April. Since we're almost mid-June, maybe a new roadmap should be published; or these issues should at least be renamed? |
|
I agree very much with you that there's a lack of transparency about where this project will be taken :) |
|
This is the current roadmap. I updated the title. |
|
Custom import resolvers please. So we could import:
|
|
Hey, is Resource Management and the |
Yes, we plan to ship it in v1.37 next month, but with a caveat that it will only work in TypeScript files. |
|
1.37 released! I was testing and was wondering if destructuring is possible with the using keyword? await using { client } = await getConnection();The deno-ts linter doesnt like it |
|
@bombillazo |
|
What does "only supported in TS files" mean? Does Deno do some transpilation to convert |
Correct, just like in TS 5.2 these directives are down emitted, the same happens in Deno using SWC. |
|
Oh, that's pretty cool! |
|
Going to close this one now. We'll come up with a new roadmap after new year. |
We’ll be writing up a more detailed explanation of this soon, but for now take a look at these examples to see how these features play together:
node-compat-app.
package.jsonspecifies dependencies, which can be imported from npm or deno.land/x."type": "module"is necessary. Lockfile used isdeno.lock.deno taskreads from deno.json first, then falls back topackage.json.deno-canonical-app.
deno.jsonsupports the import map keys. Can specify an npm package via npm specifiers or deno.land/x package via deno specifiers. Lockfile used is deno.lock. main.ts is identical in this to the first example.deno-lib
Feedback is welcome!
Tasks:
deno.json(Specify import_map.json directly in deno.json #15816 (comment))deno task- Run scripts from package.json #17492node:prefix -- ex.import { readFile } from "node:fs";(error: Uncaught (in promise) TypeError: Unsupported scheme "node" for module "node:XXX" #16223)npm:specifier usage in http/https imports (A remote module which imports npm modules requires--unstable. #17455 (comment))node:prefix a friendly error message is shown (Friendly error message when importing node built-in modules without anode:prefix #17493)Redirect module path to exact mod.ts/js index.ts/js file Redirect module path to exact mod.ts/js index.ts/js file website_feedback#10deno bundle- Ref Proposal: deprecatedeno bundle, adddeno pack#15463 but unlike this issue states, we will not add a replacement but instead allow this to be done in userland.The text was updated successfully, but these errors were encountered: