I have a dojo project which has one widget

src
    page
        index.tsx
        index.m.css
        index.m.css.d.ts
.dojorc
package.json

then run dojo build widget --mode dist --target lib, the generate files are

output
    dist
        index.d.ts
        page
            index.mjs
            index.mjs.map
            ...

then I import the Page in another project, throw errors.

// Module not found: Error: Can't resolve 'project1' in 'xx\project1\src\page'
import Page from 'project1';
// can not wirte to below, because the page folder not contain `*.d.ts`
import Page from 'project1/page';

the index.d.ts should be in page folder, not in the root folder.

Note:If has two widgets, the output is right

The test used for the istanbul-loader in the test config won't work on Windows. It should be
/src[\\\/].*\.ts(x)?$/.

As the title says, upgrade to webpack 4. May need changes in webpack-contrib.

At the moment we have to specifically target an evergreen browser to get a build that elides a lot of stuff that is now in all browsers - apart from IE11. We should flip this so we ship an evergreen bundle by default, and offer a legacy flag to build for IE11.

Finalise and document the process for developing custom widget libraries.

Ideally with a tutorial describing how to...

• create a new widget library project from scratch
• build using dojo build widget, including css and other resources
• use an unpublished widget library package in a Dojo application using npm link or similar

The output fixtures are a nightmare to maintain and are not portable across platforms. We should switch to the way we now test in cli-build-app, and that is to assert that the thing actually works in the browser. see: dojo/cli-build-app#99 and https://github.com/dojo/cli-build-app/blob/master/tests/integration/build.spec.ts

cli-build-widget should discover .spec.ts and .spec.ts.x files in the src/ directory just like cli-build-app.

cli-build-app was updated to support a separate unit and functional build, and the test build was deprecated. Do the same here!

Additionally, the output paths for the unit and functional builds should be the same as with cli-build-app, so we can use this with cli-test-intern.

Currently cli-build-widget has a single target, which is to compile a dojo widget into a custom element.

We should look to add a new "target" for building a widget library that can be be shared across multiple downstream projects. This needs to include building the widgets (to .mjs and .js), css and provide the widget typings files.

Possible example usage:

dojo build widget --target lib

Bug
Currently the behaviour of the loader resolution in webpack defaults to the root of the project, which means if you have 2 webpack related commands installed (say cli-build-widget), it can and up resolving to the wrong loaders from the other package (depending on how it's deduped by npm). To fix we should always resolve from the node_modules in this package first then the project node_modules.

resolveLoader: {
    modules: [path.resolve(__dirname, 'node_modules'), 'node_modules'],
}

The following error is thrown when running dojo build on Node 10.

node[54694]: ../src/node_file.cc:829:void node::fs::Stat(const FunctionCallbackInfo<v8::Value> &): Assertion `(argc) == (3)' failed.
 1: node::Abort() [/usr/local/bin/node]
 2: node::Assert(char const* const (*) [4]) [/usr/local/bin/node]
 3: node::fs::LStat(v8::FunctionCallbackInfo<v8::Value> const&) [/usr/local/bin/node]
 4: v8::internal::FunctionCallbackArguments::Call(v8::internal::CallHandlerInfo*) [/usr/local/bin/node]
 5: v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) [/usr/local/bin/node]
 6: v8::internal::Builtin_Impl_HandleApiCall(v8::internal::BuiltinArguments, v8::internal::Isolate*) [/usr/local/bin/node]
 7: 0x1a00db98427d

This occurs for both dojo build commands. The app is tracked at dojo/cli-build-app#93.

There is a a.jpg image at assets folder.

Then I require a.jpg at Home.ts

const png1 = require("../assets/a.jpg");
const factory = create();

export default factory(function Profile() {
	return v('h1', { classes: [css.root] }, [
		'Home Page',
		v('img', {src: png1})
	]);
});

then run npm run build(dojo build widget --mode dist --target lib) to build a dojo library, build success, but a.jpg can not open.

demo https://github.com/xiaohulu/dojo-picture

The creator of cssnext has bowed out and marked it as deprecated. It looks like it's being replaced with postcss-preset-env.

bug

In https://github.com/xiaohulu/cli-build-widget-demo, there are two widgets with the same name but place at different folders, like below:

The two widgets are all config at .dojorc

{
	"build-widget": {
		"widgets": [
			"src/a/MyWidget.tsx",
			"src/b/MyWidget.tsx"
		]
	}
}

Then run dojo build widget --mode dist --target lib, the build result only contains output/dist/b/MyWidget.*, not contains /a/MyWidget.* files.

The code place at https://github.com/xiaohulu/cli-build-widget-demo.

Version: 6.0.2

Thanks!

Given the recent issues we've had with cli-build-app, we should pin our deps and switch to using shrinkwrap to make sure we have reproducible builds for our fixture tests.

If a widget built with dojo build --target lib uses the Dojo Select widget, the build pulls in font files from the Dojo theme CSS, adding them to the output with bogus absolute paths.

These files should not be pulled in at all, as nothing in the source or output references them.

Example output:

$ dojo build widget --target lib

ℹ cli-build-widget: 1.0.0
ℹ typescript: 3.4.5
✔ hash: f509775dccfa74b71f49
✖ errors: 0
⚠ warnings: 0

chunks:

assets:
augmentedvideo/AugmentedVideo.d.ts (1.14kb)
augmentedvideo/AugmentedVideo.mjs (3.95kb)
augmentedvideo/AugmentedVideo.mjs.map (8.03kb)
augmentedvideo/Overlay.d.ts (0.17kb)
augmentedvideo/Overlay.mjs (0.06kb)
augmentedvideo/Overlay.mjs.map (0.56kb)
augmentedvideo/augmentedVideo.m.css (0.18kb)
augmentedvideo/augmentedVideo.m.css.d.ts (0.06kb)
augmentedvideo/augmentedVideo.m.css.js (0.16kb)
augmentedvideo/augmentedVideo.m.css.map (0.38kb)
augmentedvideooptions/AugmentedVideoOptions.d.ts (0.78kb)
augmentedvideooptions/AugmentedVideoOptions.mjs (2.08kb)
augmentedvideooptions/AugmentedVideoOptions.mjs.map (4.16kb)
augmentedvideooptions/augmentedVideoOptions.m.css (0.12kb)
augmentedvideooptions/augmentedVideoOptions.m.css.d.ts (0.14kb)
augmentedvideooptions/augmentedVideoOptions.m.css.js (0.33kb)
augmentedvideooptions/augmentedVideoOptions.m.css.map (0.34kb)
home/rob/repos/user_interfaces/widgets/ea_dojo_video/node_modules/@dojo/widgets/theme/fonts/dojo2.svg (15.75kb)
home/rob/repos/user_interfaces/widgets/ea_dojo_video/node_modules/@dojo/widgets/theme/fonts/dojo2.ttf (5.04kb)
home/rob/repos/user_interfaces/widgets/ea_dojo_video/node_modules/@dojo/widgets/theme/fonts/dojo2.woff (5.11kb)
output at: file:////home/rob/repos/user_interfaces/widgets/ea_dojo_video/output/dist

The build completed successfully.

I create a function-based widget at "src/PageDesigner.ts"

import { v, create } from '@dojo/framework/core/vdom';

import * as css from './styles/PageDesigner.m.css';

const factory = create();

export default factory(function PageDesigner() {
	return v('h1', { classes: [css.root] }, ['Page Designer']);
});

and add it to .dojorc

{
	"build-widget": {
		"widgets": [
			"src/PageDesigner.ts"
		]
	}
}

then run dojo build widget --mode dist --target lib

Then generate 3 files at output/dist

• PageDesigner.d.ts
• PageDesigner.mjs
• PageDesigner.mjs.map

But the dist file content is

PageDesigner.d.ts

declare const _default: import("@dojo/framework/core/interfaces").WNodeFactory<{
    properties: import("@dojo/framework/core/interfaces").WidgetProperties;
    children: import("@dojo/framework/core/interfaces").DNode<any>[];
}>;
export default _default;

Not export default PageDesigner
So I can not import the PageDesigner widget.

The demo git repo is https://github.com/blocklang/page-designer.git

It would be incredibly useful if I the widget build could support building multiple web components in a project and output a shared bundle to limit the total size of the components.

Right now if I have multiple elements in my .dojorc like this.

{
  "build-widget": {
    "elements": [
      "src/widgets/DatePicker",
      "src/widgets/Authentication",
      "src/widgets/Profile"
    ]
  }
}

Each output web component contains it's own widget source, but also all the dojo code needed as well in its bundle.

It would be really useful if we could build the whole project of web components to use a shared common.js file of the dojo code used. I assume it could work the way webpack dynamically loads files at runtime to load the common file as needed per web component. This helps cut down on the total size of js transferred.

The real benefit here is that at this point dojo could be used a source for building scalable web component libraries that could be used across multiple projects, regardless of the technology or framework being used by developers.

When running non-legacy build on a widget that imports an enum such as Keys from @dojo/widgets/common/util the build will fail / warn that Keys cannot be found.

The enum is present in the .d.ts file, but does not feature in the .js or the .m.js in the widget dist.

Currently type checking is disabled for cli-build-widget as it uses too much memory when building multiple custom elements.

We should look to see if any existing plugins (for example fork-ts-checker-webpack-plugin) can provide us with the type checking needed without consuming too many system resources.

Bug

Package Version: 6.0.0-alpha.2

Code

@dojo/widgets

OS: Windows 10

Branch: https://github.com/KaneFreeman/widgets/tree/select-dynamic-positioning

Expected behavior:

Running command npm run release -- --release=6.0.0-alpha.6 --next=6.0.0-pre --dry-run --skip-checks, which utilizes the library build should produce a usable build.

Actual behavior:

The build has the following issues:

• .tsx files are being compiled, but not having their extension renamed. Manually changing the extension of the output files to .js fixes the issue.
• The source map paths are wrong. The source map and file are in the same folder, but the parent folder name is being added.
  • Example: /*# sourceMappingURL=\text-input\index.js.map*/
  • The following error occurs when using it in a build (with cli-build-app).

    (Emitted value instead of an instance of Error) Cannot find SourceMap '\text-input\index.js.map': Error: Can't resolve './\text-input\index.js.map' in '[root_dir]\node_modules\@dojo\widgets\text-input'
    NonErrorEmittedError: (Emitted value instead of an instance of Error) Cannot find SourceMap '\text-input\index.js.map': Error: Can't resolve './\text-input\index.js.map' in '[root_dir]\node_modules\@dojo\widgets\text-input'
    

  • Changing the source map urls to /*# sourceMappingURL=\index.js.map*/ fixes the issue.

Combining both manual fixes produces a working build.

With cli-build-app, dev mode gives readable class names in both the node and the stylesheet. This is not the case with cli-build-widget.

We currently have a more verbose ident for dev that includes the filename, this causes problems when writing functional tests as the selectors change between modes, and the test bundle (which would contain the target selectors) currently uses the dist selectors.

Their is no harm in using the more verbose ident for all modes as the bundle size after gzip or related compression is likely no different.

Related to dojo/cli-build-app#154

When no command line argument for legacy is passed it is set to false even if true is passed via dojorc.

I'm having a headache trying to get functional widgets to build using the 'cli-build-widget' plugin/tool
if I run 'dojo build widget' I get a css related compile error.

./node_modules/@dojo/widgets/theme/icon.m.css
Module build failed (from 
./node_modules/@dojo/cli-build-widget/node_modules/mini-css-extract-plugin/dist/
loader.js):
ModuleParseError: Module parse failed: Unexpected character '' (1:0)
You may need an appropriate loader to handle this file type.
(Source code omitted for this binary file)
    at handleParseError 
(/home/nathan/projects/user_interfaces/test/node_modules/webpack/lib/NormalModul
e.js:432:19)...

(the widget compiles normally and unit tests run fine)
I've created a codesandbox, however I can't reproduce the error there https://codesandbox.io/s/wizardly-https-vxnql

Specifically, The following dependencies need to be replaced with @dojo/framework

• core
• has
• i18n
• widget-core
• routing
• stores
• shim.

@dojo/cli-build-app switched from using fixtures to using Cypress for its functional tests, and @dojo/cli-build-widget ought to do the same.