Plugin scaffolding is landed in aurelia-cli v1.0.0-beta.15

Framework Knowledge
1

Official guide is up too.

https://aurelia.io/docs/plugins/write-new-plugin/

11 Likes
2

This is great! Wish I saw this last week :joy:

1 Like
3

Good work :smile:

One question: I’ve created a TypeScript plugin. Is there any specific reason why declaration is set to false in the tsconfig.json?

1 Like
4

Thx. That was overlooked, carried from normal app skeleton.

1 Like
5

@huochunpeng

Thanks for your great work :smiley:

Two questions:

1 ) If I want to have multiple plugins What should I do? like the following:

bootstrap-v4
bootstrap-v5
jquery
components

Should I manage them with Lerna? (It is too hard to handle dependencies if some plugins depend on the others)

Is there any way to support multi-plugins in one package/project?

2 ) Like unit testing (Jest, …), Is it reasonable to have E2E test for each plugin or should I make another project for E2E test of the whole package/product? (Because we have no E2E test option in CLI yet.)

1 Like
6

This is great and I hate to say better late than never, but this info was sure hard to find prior.

One thing I’d love to see is a best practice for accepting options into a plugin.

1 Like
7

best practice for accepting options

Thanks for the suggestion, we will definitely enhance the doc to cover more topics. We will see what to add to the plugin skeleton, at the same time we want to keep the skeleton simple.

1 Like
8
  1. There is no official way. As plugin skeleton uses cli-bundler, it has limitation to work with in lerna hoisting. You need to update aurelia.json prepend list in every projects, because the existing prepend uses static path which assume local node_modules. With lerna, you need ../node_modules/... to reference upper level node_modules. But it should work.

Is there any way to support multi-plugins in one package/project?

Suggest you keep plugins to separated packages. We will defer the work to lerna/else to handle multiple packages in one git repo.

However, you can create shell plugin to simply wrap other plugins. Write New Plugin | Aurelia

  1. The e2e is consciously left out from plugin skeleton, as I thought e2e is more for testing app. But you can definitely copy over protractor/cypress files from an app skeleton to the plugin skeleton, in order to do e2e testing on the built-in dev-app. You might need some minor adjustment on some e2e config to get them working.
3 Likes
9

Nitpicking, but the title “Write new Plugin” should have a title like “Creating a new plugin”

1 Like
10

One more thing: a TypeScript-Plugin doesn’t create any sourcemaps. Would be great if they are generated without some extra configuration.

And a question: what do I have to configure to sourcemaps of the vendor-bundle with the built-in bundler?

3 Likes
11

To turn on sourceMap for TS plugin, update aurelia_project/tasks/transpile.ts with

export function buildPluginJavaScript(dest, format) {
  return function processPluginJavaScript() {
    typescriptCompiler = ts.createProject('tsconfig.json', {
      typescript: require('typescript'),
      module: format,
// add two lines
      sourceMap: true,
      declarationMap: true,
    });
    return gulp.src(project.transpiler.dtsSource)
// add initial identity map
      .pipe(gulp.src(project.plugin.source.js, {sourcemaps: true}))
      .pipe(typescriptCompiler())
// write sourceMap in seperate .map file.
// alternatively use {sourcemaps: true} to write inline source map
      .pipe(gulp.dest(dest, {sourcemaps: '.'}));
  };
}

I will add this cli.

For the vendor-bundle, I also struggled with source map before, but never spent enough time on it. Something is not right with the way vendor source map concats.

We do want to turn on source map for all aurelia core packages. We will definitely fix the vendor-bundle source map to support that. @bigopon, can we turn on source map in aurelia core packages build task pls?

Update: even with source map generated. App (prepared by cli) that consumes this plugin doesn’t show plugin source map properly.

3 Likes
12

Thanks!

Your “Update” is exactly the problem I’m having.
Hope this will be fixed in the near future as debugging the vendor-bundle.js is a bit time consuming :wink:

1 Like
13

Definitely, I just haven’t been able to play with that. Will start having a look

2 Likes
14

I had a look of the vendor bundle source map issue. It was a regression from a feature, support ESM format (mainly the “module” field in package.json), this feature enables better compatibility with npm packages, and inline with other bundlers’ behaviour (webpack/parcel). However, our implementation doesn’t update source map, it simply removes existing source map.

The fix wouldn’t be easy, it’s an architecture change. We need to move source map processing from final bundling step to earlier transforming step. Every transform should update source map if it exists. We will postpone that fix because we are very close to final v1 release.

1 Like
15

A walk-around is to remove “module” field from your plugin’s package.json. So app will consume the commonjs format instead of esm format dist files. This bypasses the esm+sourceMap issue in cli.

1 Like
16

Thanks @huochunpeng. I’ll give it a try later!

1 Like
17

Great to see this covered now… thanks!

One question: if I wanted to do my styling with LESS rather than CSS, what’s the best approach?

1 Like
18

Do a customised plugin and select less.

1 Like