I'm afraid we are not ready to review the potential upcoming PRs for new
locales yet. Until we have more capacity, I think it's better to keep
a low profile and not to encourage people to submit new locales.
Haoqun Jiang [Wed, 6 Dec 2023 05:44:49 +0000 (13:44 +0800)]
fix: prioritize enviornment variables over Intl.DateTimeFormat
While `Intl.DateTimeFormat` should be the most reliable way to get the
user's locale, it lacks flexibility.
For example, on Windows PowerShell, there's no way to change the
detection result in-session (you have to logout and login again).
So in order to provide an escape hatch for developers and users who
want to temporarily change the locale, we prioritize environment
variables over `Intl.DateTimeFormat`.
In POSIX shells, you can do `LANG=zh_CN.UTF-8` to change the locale to
Chinese;
In CMD, it's `set LANG=zh_CN.UTF-8`;
In PowerShell, it's `$env:LANG = 'zh_CN.UTF-8'`.
Haoqun Jiang [Mon, 16 Oct 2023 17:21:02 +0000 (01:21 +0800)]
refactor: improve locale detection
ECMA-402 support in Node.js should be reliable now, as it's building
with full-icu by default since Node.js 13. So I made it the first
choice.
Actually, I'm not even sure if the remaining variables are still useful.
But if they are used, here are my modifications:
- As for POSIX environment variables, I chose `LC_MESSAGES` over
`LC_CTYPE`, as it better reflects the purpose of the usage (we are using
the detection result to show prompt messages).
- I removed `LANGSPEC` because I can't find any documentation of it except
for one single mention in Wikipedia. I can't find any real usage of it
on my Windows machine.
- As we no longer use `LC_CTYPE`, it seems that `C` is no longer a
possible value for `shellLocale`, so I removed the fallback check logic.
If no more bug reports of Windows users are received in the coming
months, I think we can remove the TODO comment entirely.
It is a maintained fork of npm-run-all, which is not maintained anymore.
Both maintainers of the fork also maintain some other popular packages,
so I consider it a safe replacement.
Another popular alternative is [concurrently](https://www.npmjs.com/package/concurrently).
But [its size](https://packagephobia.com/result?p=concurrently@8.2.1) is too big,
I think it would be an overkill.
fix: work around vitest `mergeConfig`/`defineConfig` type issues
Until https://github.com/vitest-dev/vitest/pull/3804 is merged and
released, we can work around the issue by using the exports from `vite`,
they are identical anyway.
In later versions, we should import both `mergeConfig` and
`defineConfig` from `vitest`, though, to better align with their
official documentation.
fix: set moduleResolution: Bundler in tsconfig.node.json
It was `moduleResolution: "node"` in `@tsconfig/node18` v2, but later
changed to `node16` in v18.
This is a breaking change, and not suitable for our use cases.
We use the Node.js tsconfig for configuration files, most of which
expect either `moduleResolution: "node"` or
`moduleResolution: "bundler"` (e.g. Vite, which has its own bundling
logic for configuration file).
So in the commit, I'm setting it to `moduleResolution: "bundler"`.
I haven't seen any regressions myself, but if there are any, we can
revert to `moduleResolution: "node"`.
`node16` is obviously not compatible with many tools at the moment.
Haoqun Jiang [Tue, 13 Jun 2023 07:19:40 +0000 (15:19 +0800)]
fix: revert the `--tests` flag behavior
Fixes #297
To avoid confusions, the `--tests` flag should include exact *one* set
of test configurations. In the previous versions, it was Vitest for unit
testing and Cypress for E2E testing.
So for consistency, we remove the newly added Nightwatch template from
it.
But as we have more and more testing options, I would encourage everyone
to specify the name of the testing framework they want to use, rather
than use the general `--tests` flag. It would also be less prone to bugs
Haoqun Jiang [Mon, 12 Jun 2023 06:24:18 +0000 (14:24 +0800)]
refactor: use ejs templates for `vite.config.*` (#292)
The base template has a `vite.config.js.ejs` template file, which reads data from a corresponding `vite.config.js.data.mjs` file. The data file has a default export called `getData()`.
Other templates can also have data files that can be chained together so that they can modify the data fed into the template. They don't have to define the template again, though.
This fixes the issue mentioned in https://github.com/vuejs/create-vue/pull/257#issuecomment-1582022157
As we don't support plugins or extensions for this tool, I didn't choose to design the feature in an extensible way, but only considered ease of implementation and ease of modification.
projects / thirdparty / vuejs / create-vue.git / log
