-
Notifications
You must be signed in to change notification settings - Fork 69
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
How to convert package-lock.json to import maps? #60
Comments
Something like this should do it. You would use package.json and not package-lock.json.
|
I would think you would want to package-lock.json unless you can guarantee that all dependencies are hoisted and totally flat. |
Ah, I didn't consider transitive deps. |
Came to think of it. Do packages support a packages field? This would be crucial for node interop. Otherwise this will not be supported:
|
Exactly, package maps cannot be generated directly from the (Edit: and crawling the filesystem is fraught with edge cases like symlinks. You'd have to use The equivalent to a package-name-map is a "lockfile" format, which is usually created during an actual install. I suggested
So that's at least 3 CLI tools that need to be built, I take it? |
The |
also Yarn Plug'n'Play: Implementation should be considered - It comes with it's own file/api More Info here: yarnpkg/yarn#6382 |
Ah! very interesting. This |
oh yeah, that looks promising... unfortunately not yet useful for web components. https://github.com/daKmoR/build-pnm-webcomponent-issue I raised an issue there as well - hopefully, this will start a discussion about unique elements in a package name map. For anyone who is interested arcanis/build-pnm#1. |
Thanks for the ping! I'm entering a plane but I'll share some points regarding the build-pnm utility later today! In the meantime, can you details the reasons why webcomponents are expected to be flat, with a single version used accross an application? Since the pnm standard seems to support nested packages I wonder if there is a technical requirement I've missed in the spec 😃 |
comment moved to: arcanis/build-pnm#1 |
WebComponents is a significant change of topic from my original issue, which is asking what tools exist for creating |
Looking forward to what people produce here. I'll note that the proposal has just changed radically (and been renamed), in ways that might make this more interesting. As such let me rename the issue. |
Generates import maps from import * as lockfile from '@yarnpkg/lockfile';
import { promises as fs } from 'fs';
import * as path from 'path';
export async function getImportMap(targetPath = __dirname) {
const content = await fs.readFile(path.resolve(targetPath, 'yarn.lock'), 'utf-8');
const json = lockfile.parse(content);
return Object.assign({}, ...Object.keys(json.object)
.map(x => x.slice(0, x.lastIndexOf('@')))
.map(x => {
try {
const result = '/' + path.relative(targetPath, require.resolve(x, { paths: [targetPath] }));
return { [x]: result, [x + '/']: path.dirname(result) + '/' };
} catch {
return { [x]: undefined } ;
}
}));
} A working demo that uses import maps in browser with node_modules: https://github.com/CarterLi/web-esm/blob/master/index.ts#L27 |
Would be great to filter out development packages and generate map only for production ones. |
It's easy to filter out development packages themselves, but it's hard to filter out packages that dev packages depend on. I dont know if yarn has an API to do so, or you will have to parse package.json in node_modules recursively |
package-lock already contains this information; anything with |
Would anyone be interested in turning the two snippets above into a CLI library so that we can have all the benefits of an open source package? (I.e. modularization, the package can be upgraded centrally, etc) |
@dgreene1 Agree that we need that, but it can't really use require.resolve. Now it works relative to the file and not cwd. |
the resolve package allows a custom basedir; you could use that? |
hey there 🤗 we released a package that generates a for now, it only supports There is currently only one mode we call "flat" which flattens all your production dependencies and asks on the command line if no version can be found to can satisfy all needs. If anyone wants to work on a "nested mode" with scopes join the party on github. if you just wanna try it out... just call This is still very early - so if you can give feedback it would be highly appreciated 🤗 |
I have done something capable to generate importMap for node_modules. npm i --save-dev @jsenv/node-module-import-map
node -e "require('@jsenv/node-module-import-map').generateImportMapForProjectNodeModules({ projectPath: process.cwd() });" It recursively reads package.json and tries to find dependencies on your filesystem using a custom node module resolution. The generated import map will scope import per node module. {
"scopes": {
"/node_modules/lodash/": {
"/node_modules/lodash/": "/node_modules/lodash/",
"/": "/node_modules/lodash/"
}
} It allows each module to have import starting with import '/src/file.js' would be remapped to I give the link to the github repository in case you want to check source or unit tests for instance but the readme is empty for now: https://github.com/jsenv/jsenv-node-module-import-map. |
so cool to see everyone collaborating on new tooling for import maps 🍻 trying a different approach, i've been working on a command line tool importly generates an import map from a funny-looking
the above importly config generates an import map that uses unpkg, but also jsdelivr is set as the fallback -- the importly cli is then used like below importly < importly.config > dist/importmap.json i'm currently using importly instead of npm, as a browser package manager currently, importly doesn't integrate with npm's also, i think importly could be made isomorphic, so perhaps during development it could run in-browser and completely cut out the build step, which might be rather slick 🕶️ i'm open to ideas and discussion, just open an issue on my repo if you're interested :) cheers friends! |
Just wanting to let people know that I have a pull request up at #147 to consolidate all the tools people have been posting in this thread into the README. Also, I opened a new issue #146 to provide a general discussion space, in lieu of this issue + #108. So I'll close out this issue, but see you in #146! Thanks so much everyone for the cool stuff you've been building! |
This looks so cool! Are there any implementations of "package-lock.json -> package-name-map" translators yet? (Is that what I should be thinking of?)
(Edit by @domenic: at the time this comment was written the proposal was known as "package name maps". I've renamed the title to be "import maps", but left the body of subsequent comments alone. Sorry if that's confusing!)
The text was updated successfully, but these errors were encountered: