51–60 of 160 posts
Earlier quoted context omitted.
There are I'm sure valid reasons for doing it, but it fragments an already fragmented ecosystem. And IMHO it is ideal for there to be a first-party solution like Ruby/Bundler, Rust/Cargo, Swift/SPM, etc.
Isn't the first party solution NPM?
I may be the only one around who cares about this, but I _like_ node_modules. There are so many times where I am working on a project and either 1) I don't understand an API in a package so I quickly click into the module to learn more or 2) I find bugs, and can do a quickfix right there and then in the node_modules and test them out before submitting either a PR or work on a fork. I guess it would be possible(?) to…
Except it's exactly the same. CD into a folder.
Earlier quoted context omitted.
NPM and Yarn are both widely used for front-end JavaScript code, usually with Webpack or some other horror. Deno is an interesting model, but maybe not widely applicable?
Most browsers people actually use support ES6 modules natively now. So, bundling is sort of optional now.
You might not need to transpile your app (via babel), but you still need to bundle it (via webpack/rollup/parcel/esbuild/swc/etc)
I may be the only one around who cares about this, but I _like_ node_modules. There are so many times where I am working on a project and either 1) I don't understand an API in a package so I quickly click into the module to learn more or 2) I find bugs, and can do a quickfix right there and then in the node_modules and test them out before submitting either a PR or work on a fork. I guess it would be possible(?) to…
According to the article, it's still there, but they just renamed it to .yarn.
I do think yarn 2/3 has some way to specially cater to easily editing your npm packages.
uses patched version of typescript. Using latest version of typescript is not reliable IME.
Bugs with npm scripts are really hard to notice, the terminal output is much more pretty, but imo has regressed.
Many npm scripts are not supported. You don't get a warning for which ones are ignored.
Simply viewing the output of your npm scripts is quite annoying, if you can figure it out.
Where yarn 1 "just worked" for my co-worker on windows (I'm on mac), yarn 2 did not "just work" - he got some security prompt (Yes, Corporate Sludge)
Our security scanner (blackduck) could not properly parse the newly formatted yarn.lock file, but, thankfully, I could create a work-aroung by telling yarn2 to use `yarn2.lock` instead... and just maintain 2 lock files. (Yes, more corporate Sludge)
Also, Svelte has a variety of issues with yarn2. In theory should be solved with yarn3.
I am hopeful for yarn3. May try again once it's been iterated on a bit. Maybe once yarn4 beta is out, yarn3 will be well worth trying again.
Biggest thing to me is the typescript situation. Yarn should be completely up-front about hacks like this. Yarn2 should immediately tell you to modify your package.json to point directly to the forked version of typescript when you first run yarn install, and in the migration guide.
zero installs is very neat, but, upload speeds are always slower than download speeds. Proper CI caching+not uploading truckloads to git will be the fastest+best strategy (as long as upload speeds are slower than download)
I see absolutely no reason to upgrade. I don't have any problems with npm7 right now and I fail to see why I'd need to change all these things and learn a new tool. Maybe the patch thing. But to say that you eliminated node_modules and then introduce a new folder which will have the same files inside it... sounds like madness to me. No thanks.
That's the point, it's _not_ the same files. Instead of extracting 75K individual files on disk, the Plug 'n Play concept keeps every package as its zipped tarball on disk. So, N tarballs, one per package, instead of hundreds of files per package. Conceptually, it's great. The problem comes when all the other tools in the ecosystem are still expecting a `node_modules` folder to exist and to be able to read those indi…
The problem of wasted disk space... start using a modern filesystem like ZFS (or BTRFS, but it's less stable) that does Copy on Write and you shouldn't have these problems. Or deal with it, nowadays disk is very cheap and fast so I don't see why worrying that much.
I live with npm and that is fine, it's the most compatible solution.
I may be the only one around who cares about this, but I _like_ node_modules. There are so many times where I am working on a project and either 1) I don't understand an API in a package so I quickly click into the module to learn more or 2) I find bugs, and can do a quickfix right there and then in the node_modules and test them out before submitting either a PR or work on a fork. I guess it would be possible(?) to…
I like that.
Earlier quoted context omitted.
Most browsers people actually use support ES6 modules natively now. So, bundling is sort of optional now.
Bundling is still required to avoid HTTP waterfall that would ensure if you load raw ES modules from the browser. A real-world frontend codebase will include 100-1000+ files (via transitive dependencies), and you do not want 100+ sequential HTTP request even over HTTP2. You might not need to transpile your app (via babel), but you still need to bundle it (via webpack/rollup/parcel/esbuild/swc/etc)
But, also, you can do quite a bit with carefully selected small dependencies and a minimal amount of JS: I have some relatively complex sites that forgo bundling with no perceptible issues here
Earlier quoted context omitted.
Most browsers people actually use support ES6 modules natively now. So, bundling is sort of optional now.
Bundling is still required to avoid HTTP waterfall that would ensure if you load raw ES modules from the browser. A real-world frontend codebase will include 100-1000+ files (via transitive dependencies), and you do not want 100+ sequential HTTP request even over HTTP2. You might not need to transpile your app (via babel), but you still need to bundle it (via webpack/rollup/parcel/esbuild/swc/etc)
Unfortunately loading my app went from a second to half an hour (I think it just broke loading all the files somewhere).