Support default Yarn mode (PnP) properly (version 2.x or higher)

[nenadvicentic]

The problem:

After running npm makes aurelia in interactive mode creating template compatible to:

npx makes aurelia new-project-name -s parcel,typescript,sass

We are offered an option:

? Do you want to install npm dependencies now? » - Use arrow-keys or numbers. Return to submit.
> No
  Yes, use npm
  Yes, use yarn
  Yes, use pnpm

After choosing yarn, packages are installed and following message displayed:

Next time, you can try to create similar project in silent mode:
 npx makes aurelia new-project-name -s parcel,typescript,sass

Get Started
cd aurelia2-parcel-ts-scss-yarn
npm start

Upon running above commands, error occurs:

> aurelia2-parcel-ts-scss-yarn@0.1.0 start
> parcel -p 9000

'parcel' is not recognized as an internal or external command,
operable program or batch file.

Reason for the error

The issue happens when development machine has yarn version 2.x or higher installed and does not use node_modules folder. The behavior is called "Plug'n'Play" described here. This mode creates smallest footprint on the disk at the moment of testing - 295MB, compared to pnpm - 394MB (excluding sym-link referenced subfolders). Normal npm I did not even measure. "Plug'n'Play" also brings a lot of speed. I did not measure, but feels way faster than pnpm on initial install of packages.

Simple fix:

Perhaps "Get Started" section that is displayed after successful project scaffolding should have different text for users who selected yarn and have version 2.x or higher installed.

cd aurelia2-parcel-ts-scss-yarn
yarn start

Additional possibility - Visual Studio Code "Plug'n'Play" support.

yarn start command will do the correct work, but when using Visual Studio Code, two other improvements can be made.

As described in [Editor SDKs](yarn dlx @yarnpkg/sdks vscode) section, additional editor setup can be done by running following command:

yarn dlx @yarnpkg/sdks vscode

This will install additional package in .yarn folder and add additional configuration settings in .vscode/settings.json and extension recommendations in .vscode/extensions.json.

Perhaps option to choose editor configuration can also be added to the Aurelia scaffolding template and, when Visual Studio code is used yarn sdk integration can be executed?

[3cp]

That start print change can be easily fixed in file after.js if you'd like to make a PR :-)

[nenadvicentic]

@3cp I made a pull request with both suggestions.

However, I, while testing the skeleton, have uncovered several other, unrelated issues.

1. Source maps produced by Parcel are not working at all.
2. Webpack + yarn combination does not work at all if Yarn is in Plug'n'Play mode (this combination was possible before my changes). I suspect that it's not Webpack, but @aurelia/webpack-transformer or some other component that is causing the problem.
3. When turning on --log-level verbose on parcel I'm getting warning (due to @aurelia/runtime-html being injected to a view-model classes during the build process):

@parcel/transformer-js: Non-static access of an `import` or `require`. This causes tree shaking to be disabled for the
resolved module.

  d:\dev\GitHub\nenadvicentic\au2-parcel-ts-scss-yarn\src\my-app.ts:3:16
    2 | }
  > 3 |
  >   | ^

  ℹ Learn more: https://parceljs.org/features/scope-hoisting/#dynamic-member-accesses

It seems to me there is a lot of work to be done before basic scaffold templates work fully.

[nenadvicentic]

@3cp Just a note - I tested an example from Webpack's (version 5) getting started in combination with Yarn's Plug'n'Play. Everything works seamlessly. So issues from point 2 is likely to do with @aurelia/webpack-transformer or on of packages it depends on.

[3cp]

Both our webpack and parcel plugins have similar deps (with static import of some au2 core modules), but parcel does have special loading mechanism of plugins. If you search "yarn pnp" in parcel official repo, there are few issues going on.

[3cp]

I think the issues you experienced with webpack and parcel are same.
You explicitly added runtime and router to parcel's project deps to resolve the parcel issue. The same fix could help webpack.

Both our webpack and parcel plugins imports core au2 modules. Those core modules are not direct deps of the app project, but deep deps through umbrella "aurelia" package.

This works fine with npm which uses flat structure of node_modules which surface all deps to top level.

With yarn v1, it works the same as npm.
With pnpm, we have to use shamefully-hoist=true to use flat node_modules.

I have to do some study on yarn v2/v3 pnp. I think this is a very common catch-up for pnp users.

[3cp]

You probably can try pnp loose mode.

From what I read, pnp loose mode works similar as flat npm.