Open nenadvicentic opened 1 year ago
That start print change can be easily fixed in file after.js if you'd like to make a PR :-)
@3cp I made a pull request with both suggestions.
However, I, while testing the skeleton, have uncovered several other, unrelated issues.
@aurelia/webpack-transformer
or some other component that is causing the problem.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.
@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.
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.
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.
You probably can try pnp loose mode.
From what I read, pnp loose mode works similar as flat npm.
The problem:
After running
npm makes aurelia
in interactive mode creating template compatible to:We are offered an option:
After choosing yarn, packages are installed and following message displayed:
Upon running above commands, error occurs:
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 topnpm
- 394MB (excluding sym-link referenced subfolders). Normalnpm
I did not even measure. "Plug'n'Play" also brings a lot of speed. I did not measure, but feels way faster thanpnpm
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.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:
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?