Directory structure about node-libs-browser HOT 10 CLOSED

What is the purpose of mock? and what is in util?

What do you expect to be in the different environments?

Why is it not just:

lib
test

:)

from node-libs-browser.

mock

A good example mock for buffer.

I want the mocks to be a very small version of the buildin lib which do not implement any features to the full module, but provide a similar API.
If you now you app do not really use any feature of the vm module, but some (stupid) 3rd party lib has a reference to it, you may choose to use the mock version.

environements

Run tests with different bundlers and maybe with node. So environments are just the bindings for the bundlers to the test code in test/tests.

Why is it not just:

lib
test

Where would the shared stuff be placed? Intermixed with the modules?

from node-libs-browser.

lib/util could be better merged into lib.

from node-libs-browser.

A good example mock for buffer.

I want the mocks to be a very small version of the buildin lib which do not implement any features to the full module, but provide a similar API.
If you now you app do not really use any feature of the vm module, but some (stupid) 3rd party lib has a reference to it, you may choose to use the mock version.

This is not for this library to decide imho. Module authors can make use of the browser field which was created specifically for such things. End users can educate the bundler to further replace files. In browserify we can do bundle.require('/path/to/file', { expose: 'vm' }); to replace the vm that would load for the user if they want to opt out for all. Really this is on a per module level to decide. This module should provide as close to best effort as possible for the core libs and leave it at that. We could have a folder with some examples of smaller things but I would not expose those. Or make a different module.

Different bundlers should instrument themselves properly imho on top of a common test suite. I would not want to repeat tests over and over again. I will make an example that uses mocha testing to also work in travis, locally, and on testling to capture browser support ;)

from node-libs-browser.

This is not for this library to decide imho. Module authors can make use of the browser which was created specifically for such things.

In a perfect world they would do so 👍

End users can educate the bundler to further replace files. In browserify we can do bundle.require('/path/to/file', { expose: 'vm' }); to replace the vm that would load for the user if they want to opt out for all.

This is the use case I target to with mocks. bundle.require('node-libs-browser/lib/mock/vm', { expose: 'vm' });

Really this is on a per module level to decide.

The authors can do so which the browser field.

This module should provide as close to best effort as possible for the core libs and leave it at that.

yes.

We could have a folder with some examples of smaller things but I would not expose those. Or make a different module.

So we could have a folder for mocks, but we don't expose it. Anyone could use it by referencing the file directly. I think an extra module is too much for mocks...

Different bundlers should instrument themselves properly imho on top of a common test suite. I would not want to repeat tests over and over again. I will make an example that uses mocha testing to also work in travis, locally, and on testling to capture browser support ;)

That's that want I also wanted to do. A shared test suite with test code (test/tests) plus a few small files which just configure the bundlers to use the test suite (test/environments).

lib - shared stuff/shims i. e. objectKeys.js
  core - all libs i. e. assert.js
  mock - mocks of all libs i. e. assert.js
test
  tests - shared test suite for all environments i. e. timers.test.js
  environments - environments to run tests in with references to ../tests
    node.js
    browserify.js
    webpack.js

from node-libs-browser.

Sounds more reasonable. I would do core files right into lib. And put mock at the top level as well for shorter paths in direct access. And yes, I would not expose mock directly. Seems cool otherwise although I think we may find the environments thing is not needed.

from node-libs-browser.

So I pushed a new directory structure...

lib - all buildin libs - i.e. assert.js
util - shared stuff of the buildin libs - i.e. objectKeys.js
mock - some mocks for libs - i.e. buffer.js
test
  suite - the test cases
  browserify - run the test cases with browserify
  webpack - run the test cases with webpack

from node-libs-browser.

Exported is a plain list of modules:

require("node-libs-browser");
{
  assert: "/path/to/node-libs-browser/lib/assert.js",
  events: "/path/to/node-libs-browser/lib/events.js",
  http: "/path/to/node-libs-browser/node_modules/http-browserify/index.js",
  /* ... */
}

from node-libs-browser.

Nice. What I think I will do is make browser-resolve options take a "map" object like the one above. This way users of that module can pass in their own set of core (if they want). This will make browser-resolve not have to force any particular mappings on people. It will have a default set (based on this module).

from node-libs-browser.

I've done the same as alias option/plugin for webpack:

• https://github.com/webpack/node-libs-browser/blob/master/test/webpack/webpack.config.js#L14
• https://github.com/webpack/webpack/blob/master/lib/node/NodeSourcePlugin.js#L25

from node-libs-browser.