insin / nwb Goto Github PK
View Code? Open in Web Editor NEWA toolkit for React, Preact, Inferno & vanilla JS apps, React libraries and other npm modules for the web, with no configuration (until you need it)
License: Other
A toolkit for React, Preact, Inferno & vanilla JS apps, React libraries and other npm modules for the web, with no configuration (until you need it)
License: Other
React doesn't have built-in conventions for how you structure your apps, other than its components, which naturally define certain types of boundaries.
Despite that, any time you find yourself repeating the same thing over and over, you've effectively created a convention.
For example:
If you decided you wanted to try these conventions to quickly spin up an app, what if you could just generate new routes/route components which fit the pattern instead of having to manually create, copy and paste? (The webpack incantation for bundle splitting child routes could just be triggered by a flag, for one thing!).
There's also some boilerplate for which I always find myself referring back to documentation, official examples and previous projects, such as how to initially set up a store, middleware etc. in @gaearon's Redux with hot reloading, reducer bundle splitting and development tooling configured correctly. As much as I hate that code generation has the same problems as copy and paste after the initial convenience, if I could generate a known-good version of that boilerplate and perhaps even install the necessary dependencies in one fell swoop, it would remove a source of inertia in adding Redux to an app.
I'd also be interested in exploring a role for codemods - what if generators didn't leave you high and dry once you've generated - and especially after you've tweaked - the code, but could provide codemods which could update your dependencies and attempt to update the code to the latest version when libraries change?
Enable by default or not?
Dependencies
nwb
User config
babel.stage
is either 0-3
or falsy when providedbabel.loose
string is present in 0.12 config and treat it as its boolean equivalentbabel.runtime
flag or string to include the transform runtime pluginBabel config generation
Generate Babel 6 config using deduped-babel-config presets based on build and user config
stage
number user config as per Babel 5 and use it to choose presets.loose
as boolean user config to use an ES2015 -loose
config from deduped-babel-presetsnative
boolean build config to to use an ES2015 -native
config from deduped-babel-presetspresets
list of strings build config to to use additional named presets from deduped-babel-presetsruntime
to use the runtime transform and choose which features to enableBuild config
--preact
into account)babel-loader
when generating Webpack configbabel-polyfill
Other
(Was: Waiting for gaearon/babel-plugin-react-transform#50)
lint
script in npm run and run it, or let them configure something in the config file.new
and install and configure them for the usertype
for which they can handle or provide additional configuration for new
, clean
, build
, serve
and test
commandsCurrently, Karma tests are run in the context of nwb's install directory.
We should be able to import all plugins managed by nwb instead of using strings and having Karma import them, so changing the working directory shouldn't be necessary any more.
Benefits:
As mentioned in #43, I was probably over-influenced by trying to keep the per-config item example code small when writing the initial Configuration docs.
Nest everything under appropriate props as per babel
and karma
config:
build
config objectwebpack
config objectSpeculative future full-fat config (including changes required to support #43):
var MyConventionResolver = {
// ...
}
module.exports = function(deps) {
type: 'react-component',
babel: {
loose: 'all',
optional: ['runtime'],
plugins: [require('babel-plugin-react-html-attrs')],
stage: 0
},
webpack: {
loaders: {
css: {
query: {
modules: true
}
},
install: {
query: {
cli: {
saveExact: true
}
},
},
extra: [
// ...
]
},
plugins: {
define: {
__VERSION__: JSON.stringify(require('./package.json').version)
},
extra: [
new deps.webpack.ResolverPlugin([MyConventionResolver])
]
}
},
karma: {
tests: 'test/**/*-test.js',
frameworks: [
require('karma-tap')
]
},
build: {
umd: true,
global: 'FooComponent',
externals: {
'react': 'React'
},
jsNext: true
}
}
Hopefully the need to manually require plugins in config can also be dealt with as part of #41
Provide a built-in way to use @ericclemmons' npm-install-loader for nicer developer experience.
Edit: or https://github.com/renke/auto-install-webpack-plugin
As you are using the plugin in your npm packages I just wanted to let you know that I am planing to release html-webpack-plugin 2.x soon:
https://github.com/ampedandwired/html-webpack-plugin/tree/feature/loaders
It allows to pre render react on the server side.
The assumptions being made about node_modules and .bin currently only work for npm2 when nwb is installed locally (e.g. for a Travis CI build)
I started to make loaders configurable in 0.0.x and ended up doing a complete rewrite, plus porting to ES6.
Templates and tooling for:
Using:
nwb.config.js
in module root - default included/configured by templates
peerDependencies
)This was the cause of #21
Will need a PR to copy-template-dir to rename all files named with a leading _
, not just dotfiles.
Make this only take up one namespace slot in the config object.
Before - set umd
to false
to disable:
{
umd: true,
global: 'Blah',
externals: {
foo: 'Foo'
}
}
After - omit umd
or set it to 'false' to disable
{
umd: {
global: 'Blah',
externals: {
foo: 'Foo'
}
}
}
Technically a simple change, but it's made fiddly by copy-template-dir only supportting replacement of {{blah}}
variables, so we might need to look for something else.
We'll keep backwards compatibility with the old format plus warning messages in 0.2 and remove it in the following release.
Some webpack loaders have configuration which can't be expressed as a string, so can't use the current loaders
means of setting config, e.g. postcss-loader and stylus-loader
Add option to change the IP at the bottom of src/devServer.js
.
Being localhost
the page is inaccessible from network devices, changing it to 0.0.0.0
does the job.
Investigate using inject: true
to insert webpack assers before </body>
- the current template hardcodes them, resulting in 404s for everything but app.js when running webpack on the server.
This should also preserve the correct ordering of dependencies, as html-webpack-plugin inserts entry assets last.
Using issues for next release planning now, as Milestones are useless for tracking progress when working in the next
branch.
webpack.extra
into webpack config (replaces #43 - support adding new Webpack plugins via user config)nwb.config.js
should only be required for generic build commands which need .type
Using process.exit()
instead of throwing or calling back where appropriate makes it fiddly to test, and to test with coverage.
It's currently being used in:
src/cli.js
src/commands/build-umd.js
src/commands/new.js
src/commands/serve-react.js
src/commands/serve.js
src/createServeReactAppBuildConfig.js
src/createWebpackConfig.js
src/devServer.js
src/getUserConfig.js
src/webpackBuild.js
There's already an undocumented, untested serve-react
command.
Also add a build-react
command. (Naming? bundle-react
?)
Both should take an entry module and attempt to serve or build a React app without requiring an nwb.config.js
file to be present.
How much magic do we really want here?
Thinking about CSS preprocessors, It would be nice if you could just install an nwb-sass
, nwb-less
etc. package which would hook these up with default pipelines for static and server builds like CSS currently has. So a bit of package.json
scanning for those.
All they really need to provide is a unique name and test
and loader
config (absolute path to a dependency owned by the plugin). What if this was the entire nwb-sass
plugin?
module.exports = {
cssPreprocessor: {
sass: {
test: /\.scss$/,
loader: require.resolve('sass-loader')
}
}
}
We could potentially use whatever hook we add for this to allow the user to configure and manage their own preprocessor dependencies.
Hey, great work on nwb @insin,
Is it possible to add custom commands via nwb.config.js
into an app? Maybe if there was a way to specify what a custom command would call or do as some kind of extension/transformer. The reason I ask is because I'd love it there was some way of performing linting checks/fixes and a build
where the output is minified. Also being able to specify a custom project template when using new
and init
would be great.
Hello,
When I try to run:
nwb serve
I get the error "TypeError: The plugin "react-display-name" didn't export a Plugin instance".
Can somebody help me with this?
Test that HMR is configured correctly:
nwb serve
localhost:3000/__webpack_hmr
These seem to be the expected messages over the EventSource for a successful hot reload:
{"action":"building"}
{"action":"built","time":787,"hash":"2308f3431462588f6208","warnings":[],"errors":[],"modules":{...}
Are source maps meant to work out of the box? It doesn't seem to be the case here... In browser error reporting also has 404 links to source code, which might be related.
With this code:
import React from 'react'
import Icon from 'react-fa'
export default React.createClass({
render() {
foo(bar);
return <div>
<h2>Welcome to React!</h2>
<Icon spin name="edge" />
</div>
}
})
I get this in the browser:
I would expect error reporting to point at my code rather than at the bundled code.
webpack-hot-middleware shows build errors in the browser, which is a nicer experience.
this project looks great, but the npm version is troublingly out of date. is there anything i can do to help you upgrade?
Idea: with a locally-installed nwb have it take care of the details of creating webpack config and middleware for doing development hot reloading from your own Express server, so you don't have to mess about with proxying, and we don't have to make nwb's own dev server any more complicated.
Hypothetical usage:
app.use(require('nwb/express')(express, options))
...and nwb would do the rest.
I rely on Karma+Mocha+Chai+Phantom in my current test setup. Do you think it would make sense to allow the testing portion to be replaced with something else? Ideally I would push my setup to a package of its own and then feed it to nwb somehow (.nwb
?).
I can't see how at first glance.
To be clear about my underlying requirement I am trying to add a custom resolver as per.
http://stackoverflow.com/questions/28026428/is-it-possible-to-create-custom-resolver-in-webpack
Just scanning, PrefetchPlugin
is new to me: https://github.com/webpack/react-starter/blob/master/make-webpack-config.js
Hi,
Great work here so far - extremely useful for bringing a set of ember-cli-like conventions which is sorely needed in the React community IMO.
I am attempting to use nwb
to create a higher-order react component. The problem is that when I generate a component using:
nwb new react-component my-component
I am asked about UMD and give it a global.
It creates the directory and installs dependencies.
the resulting directory looks like this:
.
├── README.md
├── node_modules
├── npm-debug.log
└── package.json
1 directory, 3 files
However, when i create an app
with nwb, the structure is correct:
.
├── README.md
├── node_modules
├── nwb.config.js
├── package.json
├── public
├── src
└── tests
4 directories, 3 files
and with web-modules:
.
├── README.md
└── package.json
0 directories, 2 files
any idea what could be causing this?
Thanks!
This is in webpack's realm, thankfully.
Possible solutions:
resolve.fallback
, con: opens up all of nwb's modules to require() scopeCheck how easy this is to add to with copy-template-dir and create a PR
We don't want to grab a list of files in the output directory ourselves as we will be adding an nwb init
command which can create files in existing dirs.
Followed the quick start, when I get to the nwb serve part I get this error:
nwb: error running serve:
/usr/local/lib/node_modules/nwb/node_modules/qs/lib/index.js:5
const Stringify = require('./stringify');
^^^^^
SyntaxError: Use of const in strict mode.
at exports.runInThisContext (vm.js:73:16)
at Module._compile (module.js:443:25)
at Object.Module._extensions..js (module.js:478:10)
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)
at Module.require (module.js:365:17)
at require (module.js:384:17)
at Object.<anonymous> (/usr/local/lib/node_modules/nwb/lib/createWebpackConfig.js:43:11)
at Module._compile (module.js:460:26)
at Object.Module._extensions..js (module.js:478:10)
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)
at Module.require (module.js:365:17)
at require (module.js:384:17)
at Object.<anonymous> (/usr/local/lib/node_modules/nwb/lib/createServeReactWebpackConfig.js:13:28)
at Module._compile (module.js:460:26)
After reading most of the documentation I could not find any information about server sider rendering. Is this on the roadmap?
To me this would be a really valuable feature since it's probably the hardest part of the tooling.
Still a big thanks for your work so far! The react eco system will be much better of with a tool like this.
nwb version: 0.7.1
Karma issue: karma-runner/karma#1788
Same as current build but with --blacklist=es6.modules
(SInce I had to advise someone in work how to force their browser to bypass the cache today)
The current contents of template README.md
files really belong in a CONTRIBUTING.md
Drop the instructions to install globally, as this isn't necessary for contributors due to nwb
being in devDependencies
Release fix as 0.7.1 and add regression test
For people who just want a preconfigured build/serve/test pipeline
Trying a build with react-fa, it looks like CSS url()
generation is expecting publicPath
to be absolute, but the default config uses a relative path so we can deploy to a subdirectory or just open the .html file and have the app run.
nwb <= 0.7.x
Images required from JavaScript won't be resolved, otherwise.
(This also needs to be configurable for people serving apps from subdirectories)
Are you planning to add commands for publishing to github pages and publishing to npm like done by jed Watson's react component generator (https://github.com/JedWatson/generator-react-component)?
This seems obvious for the new
command:
lib/binnwb.js
process.chdir()
to itShould the server/test run stuff be done more like a smoke test?
Edit: research
Using this issue to track support for various CSS preprocessors via plugins and nwb functionality they depend on, or which needs to be added before a plugin can be implemented.
Use this issue to request more plugins..
The idea with CSS preprocessor plugins is that just installing one in your project sets up a default Webpack style loading pipeline, which you can then tweak using your nwb.config.js
file.
Use nwb to create a version of Yehuda Katz's https://github.com/wycats/github-issues-demo ember-cli demo - would be a good capability test and interesting for differences in approach (install from npm, import and use where you need it, hot reloading vs. auto refreshing)
Equivalent components from the React ecosystem:
When using redux dev tools, I get the following error:
ERROR in ./~/react-dock/lib/index.js
Module not found: Error: Cannot resolve 'file' or 'directory' /Users/geowarin/dev/react/nwb-tests/test-app/node_modules/node_modules/babel-runtime/helpers/interop-require-default in /Users/geowarin/dev/react/nwb-tests/test-app/node_modules/react-dock/lib
@ ./~/react-dock/lib/index.js 3:29-85
This path is strange: /node_modules/node_modules/babel-runtime.
The other thing is it cannot be reproduced when nwb is installed locally and linked with npm link
.
My guess is that there is something wrong with this config.
Repro here:
https://travis-ci.org/geowarin/test-app/builds/99708029
Supporting both npm 2 and 3 looks like a chore.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.