-
Notifications
You must be signed in to change notification settings - Fork 78
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
Directory structure #1
Comments
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:
:) |
mockA 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. environementsRun tests with different bundlers and maybe with node. So environments are just the bindings for the bundlers to the test code in
Where would the shared stuff be placed? Intermixed with the modules? |
|
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 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 ;) |
In a perfect world they would do so 👍
This is the use case I target to with mocks.
The authors can do so which the
yes.
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...
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).
|
Sounds more reasonable. I would do |
So I pushed a new directory structure...
|
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",
/* ... */
} |
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). |
I've done the same as |
Refactor to a better drectory structure:
The text was updated successfully, but these errors were encountered: