Modernize deno template #9932
Modernize deno template #9932
Conversation
🦋 Changeset detectedLatest commit: c5bc59b The changes in this PR will be included in the next version bump. This PR includes changesets to release 16 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
| }); | ||
| await execa( | ||
| pkgManager, | ||
| ["install", ...(pkgManager === "deno" ? ["--no-lock"] : [])], |
There was a problem hiding this comment.
the reason --no-lock is passed here is that deno v1 uses a different lockfile format to v2. when running deno install in deno v1 with DENO_FUTURE=1 set, it installs and creates a lockfile with the format of v2 which will cause errors running other deno commands without also setting DENO_FUTURE=1 env var as well. and deno install must be ran with DENO_FUTURE=1 set as deno v1's deno install does something entirely different with no good alternative (deno cache doesn't install all deps).
there's three solutions to this i can think of:
- wait for deno 2 to release and only support that, currently there are release candidates available
- force
DENO_FUTURE=1to be used for the entire project (i.e. when running any deno related command and afaik there is no configuration option for this) - do what is currently done here and don't create a lockfile in this step, let the user do it in their own time (e.g. when a command is ran like
deno task devor adding a new dependency to the project - both will automatically create the lockfile)
redabacha
force-pushed
the
modernize-deno-template
branch
3 times, most recently
from
5222ff2
to
7d7761a
Compare
redabacha
force-pushed
the
modernize-deno-template
branch
from
7d7761a
to
3daf1b6
Compare
redabacha
force-pushed
the
modernize-deno-template
branch
from
1a780f3
to
aacb0ee
Compare
redabacha
force-pushed
the
modernize-deno-template
branch
from
aacb0ee
to
ead6719
Compare
redabacha
force-pushed
the
modernize-deno-template
branch
from
78be9f6
to
0b86c3d
Compare
| let port = await getPort(); | ||
| let cwd = await createProject(await files({ port }), template); | ||
|
|
||
| // Install dependencies as late as possible so Node won't accidentally import them and cause access denied errors in Deno on Windows |
There was a problem hiding this comment.
this is my solution for this cryptic error: https://github.com/remix-run/remix/actions/runs/10672525296/job/29580157581
| export function installGlobals({ | ||
| nativeFetch, | ||
| }: { nativeFetch?: boolean } = {}) { | ||
| if (process.versions.deno) { | ||
| return; | ||
| } |
There was a problem hiding this comment.
making installGlobals a no-op in Deno allows the @remix-run/serve cli to work without issues
This modernizes the Deno template to use all the goodies of the releases over the past several years. It removes the need for a package.json file, any dependency on Node.js + npm and now uses Vite instead of the classic Remix compiler.
It also drops the need for the
@remix-run/denopackage, allowing it to be deprecated and removed in the future. I am not sure what the deprecation + removal process looks like for a remix package so I have opted to leave that out of this PR.The new Deno template is currently setup to lint the
app/directory with eslint (which Deno can run) in order to align more closely with how the other templates are setup and provide better linting rules and flexibility which is needed for web development, e.g. eslint-plugin-react-hooks gives the rules-of-hooks lint rule that Deno does not have.Furthermore, typechecking is now done with typescript's tsc for all files with
app/. This allows again for more flexibility by being able to control the typescript version and configuration independent of Deno. In order to provide Deno API access within theapp/directory (without running into typescript errors), a task calledtypegencan be run to generate the Deno specific declarations.Closes: denoland/deno#20790