The spec has moved to a repo: https://github.com/defunctzombie/package-browser-field-spec to facilitate collaboration.
This comment has been minimized.
This comment has been minimized.
Added to "Complementary Resources" section of "Front-End Package Manager Comparison": |
This comment has been minimized.
This comment has been minimized.
How would a module author provide the following:
Given a |
This comment has been minimized.
This comment has been minimized.
It is not completely related to this, but i want to extend the concept of client side (only) libraries npm. Imo the problem of client side dependencies with js, css, etc. is still not solved yet. There are tools for some parts of it but no common specification or configuration etc. What about other client side assets like css, less or images? At the moment thats completely missing in my opinion. There is already the There are tons of great client side libraries on npm but every single one is different to use / consume in the frontend when it comes to css, less, sass, images, fonts, etc. How to include them? What files should be included? In which order? It would be great if package maintainers could clearly describe what additional assets, besides javascript are shipped with the npm package and how to consume them. Lets take bootstrap as an example (original https://github.com/twbs/bootstrap/blob/master/package.json)
This could be even further extended to configure which assets are already "compiled", minified or packaged for usage or which assets are optional (bootstrap-theme.min.css). Here are some very popular packages with js, css and/or other assets on npm without any further configuration:
Package Managers like bower, component, npm or other tools like browserify, etc. could use this information only or in addition to their separate configuration files. What do you think? |
This comment has been minimized.
This comment has been minimized.
It would be great if we could expand this spec with subarg syntax: |
This comment has been minimized.
This comment has been minimized.
So this currently doesn't exist in Webpack? |
This comment has been minimized.
This comment has been minimized.
Nice spec. When you write: "browser": {
"module-a": false,
"./server/only.js": "./shims/server-only.js"
} Are the relative paths in In other words, lets say
|
This comment has been minimized.
This comment has been minimized.
A regex option would be cool, so you don't have to explicitly define each module of type to be false. |
This comment has been minimized.
This comment has been minimized.
Hey @defunctzombie would it make sense to PR this into https://github.com/npm/npm/edit/master/doc/files/package.json.md ? |
This comment has been minimized.
This comment has been minimized.
Is this added to anything besides browserify? Would be cool to see support in webpack and jspm. |
This comment has been minimized.
This comment has been minimized.
Verified this works in webpack. The property is overloaded so you sometimes have to get creative if you have a client-only entry point and want to specify a module location.
The |
This comment has been minimized.
This comment has been minimized.
@balupton It's already supported in JSPM: jspm/jspm-cli#1062 |
This comment has been minimized.
This comment has been minimized.
This use of the browser property seems to be at odds with the npm specification? It seems dangerous to me and has already caused problems with the Axios package. https://docs.npmjs.com/cli/v7/configuring-npm/package-json#browser |
This comment has been minimized.
This comment has been minimized.
It’s not at odds with it at all; they should be used in concert. |
This comment has been minimized.
Nice! I'd love to see this spec implemented in all bundlers😄