This is insane. No wonder they were motivated to create a minimal development tool. How could a CLI linter require 150 MB of disk?
> import "packages" from npm without installation
IIRC rollup does the same thing by default. This project mentions it uses rollup so maybe that’s where it’s coming from.
Using npx to run executables also does this IIRC.
And I never want it, especially if I have to opt-out. I want there to be friction to adding dependencies, it should be a carefully considered process.
Otherwise, would be curious to see how this stacks up against a moderately sized application build using webpack or vanilla rollup too. To see that, we will just need adoption over time, will keep an eye on the project!
Update: It’s not rollup that auto-installs packages, I was confusing it with parcel.
`npx`’s specific use case, though, is specifically to run scripts that you haven’t installed - else you’d use `yarn/npm run whatever`.
Huh, I wasn’t aware of that being the primary use case of npx. I assumed the primary use case was to be sugar on top of ‘./node_modules/.bin/*’, which the documentation seems to lead with too (https://github.com/npm/npx)
They immediately call out auto-installation as a feature after that, but apparently there is a ‘—no-install’ flag you can use too. I guess I would have expected this to be opt-in through ‘—auto-install’ or something is all.
Edit: I’d also add that npx has all of the same problems multiplied by being even less frictionful.
This is terrible, if you forget to add the package to your manifest, what, is the expected behavior that you just run the latest version always? Why would you want that in a production environment ever? Especially when the package manager is RIGHT THERE and already solves the problem in a well understood way. Huge step backwards IMO
Edit: It does work for e.g. pages/about/index.js to rename to index.tsx - so maybe it's just the main index that won't work as Typescript?
Also it looks like there is no default definition provided for imported CSS modules - the import resolves to a string so "styles.about" doesn't compile
FWIW the surface area for security issues here is far smaller than npx or similar tools, because WMR only writes JS/CSS/TS files to disk, and doesn't execute package scripts (where most vulnerabilities reside).
WMR's unique take is basically to be instant in every possible way, and to provide an ideal substrate for us to build and show Preact features that rely on bundler semantics. We have maintained a Webpack-based build tool for Preact for a while, and wanted to explore what a total re-think would look like. We also spent a while building out new pieces of the bundler that fit this model better than repurposing existing generalized tooling. This is one of the reasons WMR builds as fast as it does despite doing so much optimization work - it's designed around a singular goal and we allowed for very limited compromise.
I think that after a few years we will see a corresponding consolidation of the tools you mentioned, as the dust settles on this newer dev/prod split paradigm and it's effect on the bundler plugin ecosystem.
export async function prerender(data) { return { html: "<h1>hi</h1>", links: ["/other-page"] } }
Hot reloading is a similar story, it's the same API as Vite and Snowpack:
if (import.meta.hot) import.meta.hot.accept(({ module }) => { do stuff }));
<script type="module" src="./index.tsx"></script>
There are ambient TS definitions for CSS Modules, it just had a bug in 1.0.0 - fix is merged and will be released shortly.