Katja Lutz
e60ba647c6
In certain cases the handler.js copy resulted in duplicate code in the final project build. As example in the final build, dynamically imported modules might import their dependencies from the original entry-server.js instead of the handler.js copy, this would result in the following chain: 1. handler.js copied from entry-server.js (therefore has code of dep1, dep2, dep3) 2. handler.js dynamically imports SomeComponent.js 2. SomeComponent.js doesnt know about handler.js, imports dep2 from entry-server.js 3. entry-server.js has code for dep1, dep2, dep3 4. The final build includes dep1, dep2 and dep3 from handler.js and from entry-server.js So by removing the handler.js copy and directly importing entry-server.js we can avoid the duplicate dependency code. |
1 year ago | |
---|---|---|
.github/workflows | 1 year ago | |
.vscode | 2 years ago | |
components | 2 years ago | |
docs | 1 year ago | |
examples | 1 year ago | |
packages | 1 year ago | |
public | 2 years ago | |
scripts | 1 year ago | |
test | 1 year ago | |
.editorconfig | 3 years ago | |
.gitignore | 2 years ago | |
.npmrc | 2 years ago | |
.prettierrc | 2 years ago | |
.stackblitzrc | 1 year ago | |
CONTRIBUTING.md | 2 years ago | |
LICENSE | 3 years ago | |
README.md | 1 year ago | |
docs.root.tsx | 1 year ago | |
package.json | 1 year ago | |
pnpm-lock.yaml | 1 year ago | |
pnpm-workspace.yaml | 2 years ago | |
tailwind.config.cjs | 2 years ago | |
tsconfig.json | 1 year ago | |
turbo.json | 2 years ago | |
vite.config.ts | 2 years ago | |
wrangler.toml | 2 years ago |
README.md
SolidStart
This is the home of the Solid app framework. This is still a work in progress. Many features are missing or incomplete. Experimental status does not even mean beta status. Patch releases will break everything.
- File-system based routing
- Supports all rendering modes:
- Server-side rendering (SSR)
- Streaming SSR
- Client-side rendering (CSR)
- Static Site Generation (SSG)
- Streaming
- Build optimizations with Code splitting, tree shaking and dead code elimination
- API Routes
- Built on Web standards like Fetch, Streams, and WebCrypto
- Adapters for deployment to all popular platforms
- CSS Modules, SASS/SCSS Support
- TypeScript-first
Getting started
mkdir my-app
cd my-app
npm init solid@latest
npm install
npm run dev
Development
The monorepo uses pnpm
as the package manager. To install pnpm
, run the following command in your terminal.
npm install -g pnpm
Run pnpm install
to install all the dependencies for the packages and examples in your monorepo.
Monorepo & project.json
"workspace"
support
project.json
"workspace"
supportIf you are using Solid Start within a monorepo that takes advantage of the package.json
"workspaces"
property (e.g. yarn workspaces) with hoisted dependencies (the default for yarn), you must include solid-start
within the optional "nohoist"
(for yarn v2 or higher, see further down for instructions) workspaces property.
- In the following, "workspace root" refers to the root of your repository while "project root" refers to the root of a child package within your repository
For example, if specifying "nohoist"
options from the workspace root (i.e. for all packages):
// in workspace root
{
"workspaces": {
"packages": [
/* ... */
],
"nohoist": ["**/solid-start"]
}
}
If specifying "nohoist"
options for a specific package using solid-start
:
// in project root of a workspace child
{
"workspaces": {
"nohoist": ["solid-start"]
}
}
Regardless of where you specify the nohoist
option, you also need to include solid-start
as a devDependency
in the child package.json
.
The reason why this is necessary is because solid-start
creates an index.html
file within your project which expects to load a script located in /node_modules/solid-start/runtime/entry.jsx
(where /
is the path of your project root). By default, if you hoist the solid-start
dependency into the workspace root then that script will not be available within the package's node_modules
folder.
Yarn v2 or higher
The nohoist
option is no longer available in Yarn v2+. In this case, we can use the installConfig
property in the package.json
(either workspace package or a specific project package) to make sure our deps are not hoisted.
// in project root of a workspace child
{
"installConfig": {
"hoistingLimits": "dependencies"
}
}
Credits
All credit for the work on Forms and Sessions goes to the @remix-run team, MIT License, Copyright 2021 Remix Software Inc.