-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
11.0.0-beta1 is available for testing. #3131
Comments
Testing this out right now. Just writing down my notes upgrading:
Do you have an idea about when it’d be ready? |
What? You just mean
Well, now they no longer work seamlessly in VS Code (so all my linting is broken) and I'm super frustrated, but other than that...
Yeah, bunch of renaming to indicate what is private vs public.
This is a single scope that will be split into multiple classes when rendered as HTML. (this is still in flux) But if you're just talking with the emitter then you're dealing with just the scope name. It's not converted to actual classes until parse tree is converted to HTML at the very end.
Could be a little while, I'm finding the window of being free to break things to allow for a lot of progress and innovation. I'd like to cut at least one more alpha before switching to betas... but if we have a few (very solid I hope) betas then I think people can run v11 as soon as they like just so long as they are prepared for a few bumps between betas. |
For lowlight I detect that based on
Sounds like something is configured incorrectly? Now they work more like types in other projects from a user perspective. Sounds good on the time. I’m rewriting some of the outer API of lowlight too, so would be nice to get both in at the same time (although: lowlight isn’t exposing hljs APIs, so a major for hljs doesn’t need to mean a major for ll) |
Ah, indeed some stubs and older things got thrown out...
Well if you could help me fix it I'd be grateful. Before it just worked seamlessly. I've asked a bunch of people but so far it seems you can't have your cake and eat it too. |
I’m guessing it’s that you don’t import types at all! They used to be global state, which meant they could be accessed from everywhere. I use TS through JSDoc. An import there looks like this: https://github.com/wooorm/lowlight/blob/6d531acc189a414c76525d5e9a3d809d798ffd69/lib/core.js#L4. |
Yeah importing types everywhere was something I was hoping to avoid. Plus a bunch of our types are private and not exported on purpose. How does one import private types that we never export? |
Similar to how you do it with code: not completely (until export maps), but put it in a file that’s not exported. |
Any way to beautify that? It's a bit ugly/verbose. |
What’s the context? Where are you importing things? These types could be in the core lib instead maybe? |
Getting access to the types in my main source. My source is all JS, it exports no types... all the type exports are ambient modules.
I dunno what that means? You mean declare them in
I've read all that in the past. If there is a specific section you were pointing me too, please advise. |
I’m proposing the inverse: define your types in your code.
Indeed: write them in JavaScript. No need to add a manual Here’s a smaller example: words/levenshtein-edit-distance@2c3d890. I am not a fan of typescript. I personally don’t really love types either. But they are somewhat useful — especially for newcomers to a giant ecosystem (unified). Some more info here: https://github.com/voxpelli/types-in-js |
Ah, I hadn't even considered that that because I'm not really interested in adding TS to our build pipeline (in my prior experience it's ridiculous slow). Something to consider for the future perhaps. I just got the ambient module stuff working and not interested in burning more time on this now. I will save all those references for future reference though. |
I am, but not sure it's right for our codebase since it further limits who can contribute and I think we get many of the benefits with JS doctags alone.
I find they make me a lot more thoughtful/disciplined about the API of functions and shape of objects. This has been helpful. |
Having some problems as I’m no longer allowed to use extensions. https://github.com/xojs/xo is configured to enforce them. I quite like being explicit instead of magic, and would prefer to be allowed to use actual paths. |
At the back of my mind something is saying "This is the new standard, people will need to update their linters" , but I'm not sure where I'm getting that from. All the Node.js examples with conditional exports seem to show lack of extensions IIRC, so I guess perhaps that's at least one place that left me with that impression. I do think what your asking is at odds with the whole IDEA of conditional exports though... you're not longer specifying REAL paths OR files at all, just identifiers (that the package routes however it chooses)... so to me the "spirit of the law" behavior seems to remove the extensions. No point pretending to be explicit if it isn't really. I mean it's actually explicit all the way down, just not the way you're used to... @aduh95 Any thoughts? Of course if we end up walking back conditional exports before release this will cease to matter as you'll still just be able to import anything you wish... |
I’d say we used to do extensionless — now we do explicit extensions. |
I can't keep track because I feel it's changed a few times, I think TS had different ideas than JS for a while, and now conditional exports seems to be hinting at extension-less behavior I thought... I'm curious to see how other packages approach this. The browser can only deal with files of course (without forcing the resolution behavior back onto the web server itself) so I'd say it was "stuck" without much of a choice... If found necessary I think the extension based paths could just be added to the exports table beside the path based, could you confirm? |
Also: for xo and Sindre and me: this is folks who used to do extensionless, and are now switching to extensions. I also don’t like export maps much. But it indeed seems that that prefers no extensions. So I don’t know 🤷♂️ |
I dunno what to think yet... the promise is that ESM and CJS "just work" and no one has to think about |
Oh and preventing people from reaching into pieces of your library that are intended to be private is a nice benefit - though it doesn't really apply to us at the moment since we have a build process and if we don't want to expose it we just don't build it separately. |
Yes, exactly, the goal of conditional exports is to hide where the files happen to be in the npm archive, as it's considered an implementation detail. The idea is that |
I guess most of your users are using generated bundles though, where it doesn’t matter. I’d suggest to push for folks who are depending on the files to upgrade to ESM. Dual publishing is complex! ESM is closer to having files directly usable in browsers too.
And I think that’s the problem. That promise seems to fail all the time 😬 |
What is the "it" this is referring to?
Huh, I'm not following? Which files and what do you mean "upgrade to ESM"?
Well the v11 release isn't necessarily going to happen until post Node v10 sunsetting, so there is still time for the situation to improve.
Indeed, but we're not shipping two separate packages and I'm not a fan of this fervor to immediately "switch" the whole ecosystem to ESM, so that means we either ignore ESM for another release cycle or ship dual... and shipping dual seemed the better of those two choices to me. |
“It” here refers to module format (ESM vs CJS vs dual) — which doesn’t matter to bundle/CDN users
I suggest that package maintainers start switching to ESM only.
That’s in 7 days already! |
Most of the reading I've seen on this is based on "just keep using our prior version if you still need CJS, easy!" which is NOT a philosophy we want to embrace. We do not want tons of people on v10 forever anymore than we wanted tons of people on v9 forever after v10 was released. The best experience is always on the latest and we don't want to give people reasons NOT to upgrade.
I agree for a whole lot of people just happily using our CDN module that this is an entire non-issue. And our browser/CDN builds aren't changing.
Oh, LOL..... well then it'll be after Node v10 I guess... I'm really looking for some actual feedback with bundlers (or something) and such things where people literally can't use the library because something is broken broken. So far all we have is your wishing the paths could have extensions. I assume if you removed the extensions it worked fine (though you haven't said). Also, the ~ official support window for Highlight.js v10 is ~ 3 months or so... so if a bundler doesn't support conditional exports yet but plans to soon that's also OK I think. |
I’m not suggesting users use CJS. I’m suggesting they use ESM
Some more info here: https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c. I don’t know about conditional exports support in bundlers, as I don‘t use that myself.
|
Right, but ESM only is a reason for someone not to upgrade if their codebase is "stuck" on CJS. I don't want to do anything to encourage "well we'll just keep using v10, it works". |
Definitely. highlight.js is relatively “high-level” project, with many beginners, compared to most of Sindre’s or my stuff. And it’s relatively unique at that for having no dependencies. Generally I think these changes “bubble upwards” through the ecosystem, from low-level one-liners, through more user-facing projects, to users. I think you have some options and that choosing to not be one of the first to switch is a fine strategy. On the other hand, most of your users won’t notice and the folks that do depend on it through npm are (presumably) aware of the CJS -> ESM move, and it might cause them to switch faster! |
Yeah, I just wish I had more stats. I just feel like v11 already has enough breaking changes and we already "force" our users to do enough (stay up-to-date with releases, including hopefully major ones)... all of this ultimately to serve their interests though - since we can only maintain a single version - the benefit they receive is new features, better grammars, bug fixes, etc... so there is a [hopefully] clear benefit to offset any annoyance. At this point I just can't see the direct payoff for forcing users to upgrade to ESM if they don't wish to. Our codebase is ESM already. The final format of our build assets (ESM or CJS) honestly isn't very interesting to me. Now we'll just have 3 output formats instead of 2 and users can use whichever works for their usage. If that proves to be some sort of maintenance headache we'll see, but I'm not imagining it will be. |
How to get it:
npm install [email protected]
11.0.0-beta1
tag)Please open a new issue if you have bugs or issues to report.
The text was updated successfully, but these errors were encountered: