dojo / cli-build-webpack Goto Github PK

Bug

Currently if we build (with no auto bundling) a project that uses load(require, './MyWidget') and the module is imported in unit tests, the tests fail for Missing module: src/MyWidget.

Expected behaviour is to ensure that modules are added to the map in CoreLoadPlugin if they are imported in the unit tests even if the load is registered in the projects src directory.

Bug

Per https://github.com/dojo/meta/blob/master/LICENSE#L10-L17 , users of Dojo should include a copy of the license in their usage of Dojo. Our current build does not do this.

Expected behavior:

The following comment should be included in all built code:

/*
[Dojo](https://dojo.io/) 
Copyright [JS Foundation](https://js.foundation/) & contributors
[New BSD license](https://github.com/dojo/meta/blob/master/LICENSE)
All rights reserved
*/

Actual behavior:

Currently no copyright or license information is included in any built code

Enhancement

We currently do not apply any CSS optimization to our build output so we have some duplicated classes (due to css-module composition) and unused variable blocks as well as whitespace and non-shorthand style definitions.
Adding the optimize-css-assets-webpack-plugin webpack plugin for dist builds will achieve this for us.

Example code

...includeWhen(!args.watch && !args.withTests, (args) => {
   return [new OptimizeCssAssetsPlugin()( options )];
}),

[nit] compose is no longer used in this repo so we can remove the dep.

Can we either publish "source-map-loader": "bryanforbes/source-map-loader#463701b", or remove the dep for something else please?

At the moment, you cannot use the cli to bootstrap a project unless you have git installed and relying on non-publically-versioned things is not great.

Bug

It looks like the build command is pulling in it's own node_modules ahead of the projects modules.

Situtation:

When testing cli build with the kitchen sink, I was running into an issue where the wrong @dojo/core was being pulled in. The project looked like this:

<project>
    node_modules/@dojo/core (version alpha.26)
    node_modules/@dojo/cli-build-webpack/node_modules/@dojo/core (version alpha.25)

Upon doing a dojo build, core alpha.25 was being included in the bundle, rather than alpha.26.

@rishson commented on Tue Oct 04 2016

Refs dojo/meta#55

@mwistrand commented on Sat Oct 29 2016

Since dojo-i18n allows multiple locales to be used simultaneously and for locale data to be loaded dynamically, the main obstacle to incorporating dojo-i18n into the build process is ensuring that the CLDR data and locale messages are loaded only once.

The CLDR data are loaded via dojo-core/request and then cached locally, and the locale messages are loaded via dojo-core/load and then cached locally. Since the locale messages are proper modules, theoretically they should pose no problem since the build will have already loaded them. The CLDR data, however, are JSON files. As such, pointing to the appropriate cache in both development and production is a more difficult problem. One solution is to write an additional module that converts the CLDR JSON files pulled from unicode.org into UMD modules, so that they can be imported by dojo-core/load and cached by the underlying loader.

With regard to webpack, @matt-gadd, @agubler, @tomdye, and I had discussed using globalize-webpack-plugin, but found that doing so would require changes to the dojo-i18n message structure and would mean loading CLDR and message data twice in development.

Whichever solution we settle on, the following are still required:

1. A default locale.
2. An array of locales that should be included in the final build. Any default locale that has been specified will be assumed and not required in this list.
3. An array of paths to bundle directories. Any files found under ${path}/{locale}/ (where {locale} is one of the locales listed in no. 2 above) will be included in the build.
4. All CLDR data for the locales listed in no. 2 above are included in the build.
5. It should still be possible to dynamically load any other CLDR data or messages for locales not explicitly included in the list of supported locales.

Bug

When using --watch, the test source files are not always recompiled when they should.

Steps to reproduce:

1. Create an app: dojo create --name test
2. From the app directory, start the build: dojo build --watch.
3. Rename src/App.ts to src/App1.ts.
4. Notice the build watcher recompiles src/main.ts and tests/unit/App.ts and reports errors.
5. Edit tests/unit/App.ts and change the failing import statement to
   import App from './../../src/App1';
6. Notice no recompile occurs.
7. Edit src/main.ts and fix the import statement.
8. A recompile occurs but it still reports an error in tests/unit/App.ts even though the code had been updated.
9. Stop the build watch command and rerun it.
10. No compile errors.

Should the build watch command be compiling the test source files at all? I am not going to answer that question. But if there are cases when it is going to compile the files and report errors, then it needs to recompile them when I fix the errors.

Enhancement

When using @dojo/core/load to lazy load a module, we want automatically add the module to its own bundle

Given,

registry.define('my-widget', () => {
    return load(require, './MyWidget')
        .then(([ MyWidget ]) => MyWidget.default);
});

We want cli-build to add MyWidget to it's own bundle using something like,

require(`bundle-loader?lazy&name=${widgetName}!./Widget`);

Bug

The node request provider should not be required and therefore should be ignored from the build bundle.

Bug

Need to add an image loader.

Bug

When running dojo build -w --with-tests (or dojo build -w -t) an error occurs config.entry[key].unshift is not a function.

Package Version: Alpha.1

Enhancement

Currently, when using the watch flag (dojo build webpack --watch) the application's state is disposed of whenever a change is made. This reduces the usefulness of the watch feature when working on a use-case that requires the application to be in a certain state to get to the feature that is being worked on.

This enhancement is intended to either modify the behavior of the watch command to preserve state or, optionally, add another flag that would allow state to be maintained.

Add README.md details for cli-build.

We need to determine how, when using Dijits in Dojo 1 what will happen from a build perspective.

Enhancement

Per dojo/i18n#83, the build should account for the possibility of a context require function being passed to @dojo/i18n/cldr/load.default when statically extracting CLDR URLs. Currently, the parser assumes the list of URLs will be passed as the first argument.

Bug

It looks like you can't build code that imports CSS modules that aren't in the src/ directory. I think it's a problem with src/loaders/css-module-dts-loader/loader.ts#getCssImport.

This was discovered while looking into dojo/meta#138 .

Code

import * as localStyles from './some/local/file.m.css';
import * as foreignStyles from '@dojo/widgets/common/styles/base.m.css';

You can error when running dojo build.

Expected behavior:

I expect it to build 😄

Actual behavior:

(node:28421) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: ENOENT: no such file or directory, stat '/Users/rorymulligan/Desktop/dojo2/examples/todo-mvc/src/@dojo/widgets/common/base.m.css

Bug

dojo/cli-build uses a loader that forces the AMD portion of UMD wrappers to be skipped, but it is specific to the UMD wrappers generated by TypeScript (specifically by searching for the presence of var v = factory(require, exports); if (v !== undefined) module.exports = v;. As such, the build still chokes on UMD modules with different wrappers.

Package Version: All versions, including alpha.6

Code

// The following UMD wrapper is correctly bypassed
(function (dependencies, factory) {
    if (typeof module === 'object' && typeof module.exports === 'object') {
        var v = factory(require, exports); if (v !== undefined) module.exports = v;
    }
    else if (typeof define === 'function' && define.amd) {
        define(dependencies, factory);
    }
})(["require", "exports"], function (require, exports) {});

// The following UMD wrapper is not bypassed
(function(global, factory) {
	if ( typeof define === 'function' && define.amd ) {
		define([], factory);
	} else if ( typeof exports === 'object') {
		module.exports = factory();
	}
}( this, function() {});

Bug
The webpack-dev-server client module is being incorrectly resolved.

Steps to reproduce

Run dojo build -w

Expected behavior:

To not throw an error.

Actual behavior:
Webpack Module not found: Error: Cannot resolve 'file' or 'directory' for webpack-dev-server/client

It looks like the solution is to monkey-patch fs using graceful-fs inside the webpack.config.js file: webpack-contrib/copy-webpack-plugin#59 (comment)

EDIT: tried that, didn't work. Looks like other solutions are proposed further down the thread.

EDIT 2: updating dojo-cli-build-webpack to use copy-webpack-plugin v4.0.1 seems to have solved the problem.

The API for Compilation#buildModule() changed in Webpack 2 and InjectModulesPlugin was not updated to accommodate this change. Currently, the following is done:

compilation.buildModule(module, (error?: Error) => {

But it should be called like so:

compilation.buildModule(module, false, null, null, (error?: Error) => {

I discovered this while writing typings for Webpack for #53.

Bug

cli-build now supports auto and manually defined bundles, but the bundle analyser only supports a single bundle outputting the last created bundle only.

The analyser should support multiple bundles and create a report/reports that reflect them.

Enhancement

We should support CSS modules written in Stylus.

css-module-typings should be created as part of our webpack build process. Furthermore they should be included in the watch process such that they are generated as they are edited.
An attempt was made to use typed-css-module-loader but this was not sufficient. There are outstanding PR's and issues on this loader which may provide a solution but it's likely that we may need to create a typescript pre-loader which plucks out the .css imports and creates the appropriate typings.

Bug

The build currently fails on Windows. The TypeScript loader doesn't appear to find targeted files, as no compilation takes place.

Code

$ dojo build
Hash: f11b80610fe96c355d9f
Version: webpack 1.13.3
Time: 5982ms
                           Asset       Size  Chunks             Chunk Names
                       main.styl    0 bytes          [emitted]
                     src/main.js    1.89 kB       0  [emitted]  src/main
                 src/main.js.map    1.88 kB       0  [emitted]  src/main
                    main.css.map   85 bytes       0  [emitted]  src/main
                      index.html  253 bytes          [emitted]
                        main.css   36 bytes       0  [emitted]  src/main
                 styles/app.styl   39 bytes          [emitted]
 styles/structural/_css/test.css   37 bytes          [emitted]
styles/structural/_css/test2.css   38 bytes          [emitted]
      styles/structural/test.css   28 bytes          [emitted]
     styles/structural/test2.css   29 bytes          [emitted]

ERROR in src/main.js from UglifyJs
SyntaxError: Unexpected token: name (css) [./src/main.ts:2,0]
Child html-webpack-plugin for "index.html":
         Asset    Size  Chunks       Chunk Names
    index.html  1.6 kB       0
Child extract-text-webpack-plugin:

Expected behavior:

The build should log information about ts-loader and tsconfig.json and actually compile TypeScript.

Actual behavior:

No typescript compilation occurs.

Bug

After moving to @dojo the source map preloader configuration needs updating to reflect the new module names.

** Enhancement**

TSX extensions and RXJS alias are no longer required in our webpack config thus should be removed.

Enhancement

Having started a Dojo 2 project, it would be very helpful if the build included running tslint on build and watch.

We could include the tslint-loader based on whether project has a tslint.json included.

Perhaps something like:

	let tslintExists = false;
	try {
		require(path.join(basePath, 'tslint'));
		 tslintExists = true;
	} catch(err) {
		// do nothing
	}

...includeWhen(tslintExists, () => {
	return [
		{
			test: /\.ts$/,
			enforce: 'pre',
			loader: 'tslint-loader',
			options: {
				tsConfigFile: path.join(basePath, 'tslint.json')
			}
		}
	];
}),

Enhancement

We should add reporting to the build so people can profile the bundles they are generating. This should only be ran on a prod dojo build (not dev mode with -w). There are 2 good plugins for webpack out there:

https://github.com/th0r/webpack-bundle-analyzer - creates a tree map and supports both post minification and gzipped analysis of bundles. One issue might be that I think the visualization it creates is provided by a library which is commercial - so might want to check that.

https://github.com/chrisbateman/webpack-visualizer - generates a pretty sunburst visualization, but as far as i'm aware only shows sizes pre minification.

Enhancement

Currently web fonts break our webpack build.
Need to add a font file, or any file catch all to our webpack config to load via file-loader

Enhancement

Prevent uglify from running for development builds.

Would it be possible to find a way to pass additional arguments to webpack? In particular it might be handy to be able to pass the --json argument to be able to generate webpack stats for analysis. With the zero configuration nature of the CLI it become challenging to figure out how to get webpack to run standalone.

Enhancement

Given a .dojorc like this:

{
    'build': {
        'bundles': {
             'foo-bundle': [
                 './src/todo/Foo',
                 './src/something/Else'
             ]
        }
    }
}

Create a bundle foo-bundle consisting of the given files.

If you run multiple dojo build -w then you'll get:

$ dojo build -w
events.js:160
      throw er; // Unhandled 'error' event
      ^

Error: listen EADDRINUSE 127.0.0.1:9999
    at Object.exports._errnoException (util.js:1022:11)
    at exports._exceptionWithHostPort (util.js:1045:20)
    at Server._listen2 (net.js:1262:14)
    at listen (net.js:1298:10)
    at doListening (net.js:1397:7)
    at _combinedTickCallback (internal/process/next_tick.js:77:11)
    at process._tickCallback (internal/process/next_tick.js:98:9)

Might be nice to capture this error and just say:

Cannot start a build server because you already have one running.

Review the generated API documentation for cli-build at http://dojo.io/api/. If any of the information is not accurate, please make the necessary adjustments to the API documentation within this repo.

We should expand the README with:

• what the build does
  • what gets built and where
  • why this is beneficial (size etc)
  • what is part of the build (sourcemaps, js rather than ts, css and why it looks weird)
  • what our widgets look like once built (what they contain etc)
• how the build does it (uses webpack, but light on details)
• cover the various scenarios, build for dev, build for prod..

Enhancement

The current webpack config internalizes the css into the js bundle. This although cuts down on network requests, causes a flicker of unstyled content on page load, as well as increasing the size of the bundle.

Enhancement

dojo/cli supports now ejecting configuration for advanced users. The eject should be implemented for the build configuration.

Bug

webpack.config.js uses an unsafe regex when configuring the ContextReplacementPlugin.

Enhancement

When building an application with localized message bundles, the bundlePath specified by the default bundle must be the full path from the current working directory. However, since it is assumed that all application source will be included in the src/ directory, it would be nice if that root directory were assumed by the build. That would allow message bundles to specify their bundle paths without that root directory. For example, a bundle at src/nls/common.ts could specify its bundlePath as just nls/common instead of as src/nls/common.

@rishson commented on Mon Oct 03 2016

A lá dojo1.

@kitsonk commented on Mon Oct 03 2016

Refs dojo/meta#34

@matt-gadd commented on Fri Oct 14 2016

@rishson can we state the problem rather than dictating a solution. there are a variety of ways we will want to make our apps performant at build time.

@rishson commented on Fri Oct 14 2016

@matt-gadd fair point. I'll create a 'performance' epic on cli to start discussion on what we can do to create well behaved, performant apps.

@kitsonk commented on Fri Oct 14 2016

So are we keeping this open then?

As far as a user story, I would say this one is one like this:

In complex web applications with multiple views, where certain views were in order to have a functional application, not all modules are needed to be loaded upon page load, and groups of modules, with any additional dependencies not already loaded, can be loaded efficiently.

In Dojo 1, this was accomplished by allowing the developer to group modules into logical sets which then allowed the developer to specify "layers" to allow efficient incremental loading of code and other resources as triggered by certain actions in the application.

@agubler commented on Fri Oct 14 2016

I think that this would certainly warrant being kept open as a story, maybe under the wider performance epic.

@agubler commented on Wed Feb 01 2017

This should probably be moved to cli build, but with more details of the problem

While updates to the webpack configuration itself should and will be handled by the eject command (dojo/cli#44), certain options justify an application-level config. For example, the user should be able to set the application's default locale and any supported locales. As such, the build process should check for the existence of something like path.join(process.cwd(), 'dojo.config.js') and read any values it needs to feed into the configuration.

Document how to configure webpack for builds. Should probably add a better README file as well.

Enhancement

With @dojo/[email protected], we can remove cldr-data as a dependency. This also includes updating the i18n plugin to extract arrays of URLs passed to @dojo/i18n/cldr/load.default. As with use of @dojo/i18n, users will be required to provide their own CLDR data, but at the same time are not required to include it if their application does not need it.

With this update, users will be able to load CLDR data as follows:

import loadCldrData from '@dojo/i18n/cldr/data';

loadCldrData([
	'cldr-data/main/{locale}/currencies.json',
	'cldr-data/main/{locale}/numbers.json',
	'cldr-data/supplemental/currencyData.json',
	'cldr-data/supplemental/likelySubtags.json',
	'cldr-data/supplemental/numberingSystems.json',
	'cldr-data/supplemental/ordinals.json',
	'cldr-data/supplemental/plurals.json'
]);

At build time, the URLs will be extracted and loaded, and any URL with a {locale} token will be loaded for both the defaultLocale as well as any supportedLocales.

Enhancement

The build is capable of including all data for a set list of locales, and applications can switch between those locales at runtime, but it would useful to also provide a means of building other locale data into separate webpack chunks so that they can be loaded dynamically. For example, if I have an application that supports English and Spanish by default, but I also want to localize my application for French speakers without incorporating that additional data into the main build, it would still be possible to retrieve all French messages and CLDR data via an additional HTTP request.

Now we're moving the WebPack config over to TypeScript, we should make an effort to properly type it.

Add support for stylus now its our officially chosen preprocessor.

It has been the source of some confusion that the repo is called cli-build but the package is called cli-build-webpack.

I think we should isolate ourselves from a specific implementation (in this case webpack) and rename the repo to cli-build-app and use this name for the published package.

We should remove the dojo/stores dep from the boilerplate package.json. Whilst the dojo/stores dep is OK in itself, it has a peer dep of dojo/compose so will raise warning on running dojo create if compose is not found.