browser field spec for package.json · GitHub

browser field spec for package.json

Raw

The spec has moved to a repo: https://github.com/defunctzombie/package-browser-field-spec to facilitate collaboration.

jhnns commented Feb 13, 2013

Nice! I'd love to see this spec implemented in all bundlers 😄

wilmoore commented Feb 23, 2013

Added to "Complementary Resources" section of "Front-End Package Manager Comparison":
http://git.io/_ZWfVA#complementary-resources

kirbysayshi commented Nov 13, 2013

How would a module author provide the following:

themod.js (authored directly, CJS style)
themod-amd.js (generated at publish time)

Given a package.json that had a browser field, should the module author even attempt to provide both files? Should the author specify transforms, and rely on the consumer using a tool the author specified a transform for? It would be nice if the consumer could use the same identifier in both scenarios.

This comment has been minimized.

Show comment

Hide comment

thomasfr Nov 7, 2014

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 directories property in the CommonJS spec, but it is missing keys for static assets like css, less, images, etc. (http://wiki.commonjs.org/wiki/Packages/1.0#Optional_Fields and https://www.npmjs.org/doc/files/package.json.html#directories)

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)
Why not?


{
  "name": "bootstrap",
  "description": "The most popular front-end framework for developing responsive, mobile first projects on the web.",
  "version": "3.3.0",
  "homepage": "http://getbootstrap.com",
  "author": "Twitter, Inc.",
  "scripts": {
    "test": "grunt test"
  },
  "directories": {
    "assets": {
       "css": ["dist/css/bootstrap.min.css","dist/css/bootstrap-theme.min.css"],
       "js":["dist/js/bootstrap.min.js"]
       "font":["dist/fonts/glyphicons-halflings-regular.eot","dist/fonts/glyphicons-halflings-regular.eot","dist/fonts/glyphicons-halflings-regular.svg","dist/fonts/glyphicons-halflings-regular.ttf", "dist/fonts/glyphicons-halflings-regular.woff"]
    }
  },
  "main": "./dist/js/npm",
  "repository": {
    "type": "git",
    "url": "https://github.com/twbs/bootstrap.git"
  },
  "bugs": {
    "url": "https://github.com/twbs/bootstrap/issues"
  },
  "license": {
    "type": "MIT",
    "url": "https://github.com/twbs/bootstrap/blob/master/LICENSE"
  },

  "jspm": {
    "main": "js/bootstrap",
    "directories": {
      "example": "examples",
      "lib": "dist"
    },
    "shim": {
      "js/bootstrap": {
        "imports": "jquery",
        "exports": "$"
      }
    },
    "buildConfig": {
      "uglify": true
    }
  }
}

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?
cheers

thomasfr commented Nov 7, 2014

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 directories property in the CommonJS spec, but it is missing keys for static assets like css, less, images, etc. (http://wiki.commonjs.org/wiki/Packages/1.0#Optional_Fields and https://www.npmjs.org/doc/files/package.json.html#directories)

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)
Why not?


{
  "name": "bootstrap",
  "description": "The most popular front-end framework for developing responsive, mobile first projects on the web.",
  "version": "3.3.0",
  "homepage": "http://getbootstrap.com",
  "author": "Twitter, Inc.",
  "scripts": {
    "test": "grunt test"
  },
  "directories": {
    "assets": {
       "css": ["dist/css/bootstrap.min.css","dist/css/bootstrap-theme.min.css"],
       "js":["dist/js/bootstrap.min.js"]
       "font":["dist/fonts/glyphicons-halflings-regular.eot","dist/fonts/glyphicons-halflings-regular.eot","dist/fonts/glyphicons-halflings-regular.svg","dist/fonts/glyphicons-halflings-regular.ttf", "dist/fonts/glyphicons-halflings-regular.woff"]
    }
  },
  "main": "./dist/js/npm",
  "repository": {
    "type": "git",
    "url": "https://github.com/twbs/bootstrap.git"
  },
  "bugs": {
    "url": "https://github.com/twbs/bootstrap/issues"
  },
  "license": {
    "type": "MIT",
    "url": "https://github.com/twbs/bootstrap/blob/master/LICENSE"
  },

  "jspm": {
    "main": "js/bootstrap",
    "directories": {
      "example": "examples",
      "lib": "dist"
    },
    "shim": {
      "js/bootstrap": {
        "imports": "jquery",
        "exports": "$"
      }
    },
    "buildConfig": {
      "uglify": true
    }
  }
}

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?
cheers

majgis commented Dec 31, 2014

It would be great if we could expand this spec with subarg syntax:
browserify/browserify#1046

adjavaherian commented May 4, 2015

So this currently doesn't exist in Webpack?

djfm commented Jun 15, 2015

Nice spec.

When you write:

"browser": {
    "module-a": false,
    "./server/only.js": "./shims/server-only.js"
}

Are the relative paths in "./server/only.js": "./shims/server-only.js" relative to the location of the package.json file or to the directory of the file that calls require('./server/only.js')?

In other words, lets say root stands for the directory where the package.json is located and root/deep/file.js does require('./server/only.js'), should it resolve to:

root/deep/shims/server-only.js
or to root/shims/server-only.js?

adjavaherian commented Jul 23, 2015

A regex option would be cool, so you don't have to explicitly define each module of type to be false.

zeke commented Sep 8, 2015

Hey @defunctzombie would it make sense to PR this into https://github.com/npm/npm/edit/master/doc/files/package.json.md ?

balupton commented Sep 19, 2015

Is this added to anything besides browserify? Would be cool to see support in webpack and jspm.

This comment has been minimized.

Show comment

Hide comment

watsoncj Sep 25, 2015

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.

"main": "index.js",
"browser": {
  "index.js": "bytebuffer/dist/ByteBufferAB.js",
  "Long": "bytebuffer/node_modules/long/dist/Long.js"
}

The index.js mapping is equivalent to "browser": "dist/ByteBufferAB.js"

watsoncj commented Sep 25, 2015

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.

"main": "index.js",
"browser": {
  "index.js": "bytebuffer/dist/ByteBufferAB.js",
  "Long": "bytebuffer/node_modules/long/dist/Long.js"
}

The index.js mapping is equivalent to "browser": "dist/ByteBufferAB.js"

chauthai commented Oct 6, 2015

@balupton It's already supported in JSPM: jspm/jspm-cli#1062

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

You can’t perform that action at this time.