2022-06-09 20:18:06 -04:00
# Contributing to SolidJS
Thank you for investing your time in contributing to our project! ✨.
Read our [Code of Conduct ](https://github.com/solidjs/solid/blob/main/CODE_OF_CONDUCT.md ) to keep our community approachable and respectable. Solid accepts a number of contributions from the broader community. More hands indeed make lighter work. We're however selective of the types of contributions we receive.
This usually involves vetting code quality, current focus, alignment with team philosophies etc. It's typically a good idea to submit a proposal for a change before spending time implementing it. This is to ensure that your efforts align with the current needs or more practically that work isn't completed by multiple contributors.
Note: If you would like your project listed here please submit a PR or contact a core/ecosystem member on Discord.
## Team Structure & Organization
There are a lot of opportunities to get involved. We organize Solid community efforts via Discord and typically onboard dedicated contributors into focused teams:
2024-05-24 11:50:30 -07:00
- Docs (headed by [@LadyBluenotes ](https://github.com/ladybluenotes ))
2022-06-22 05:56:57 +02:00
- Infrastructure (headed by [@davedbase ](https://github.com/davedbase ))
- Advocacy (headed by [@hindsight ](https://github.com/eslachance ))
2022-07-13 10:53:27 -04:00
- Growth (headed by [@davedbase ](https://github.com/davedbase ))
2022-06-22 05:56:57 +02:00
- Translators (headed by [@davedbase ](https://github.com/davedbase ))
2022-06-09 20:18:06 -04:00
2022-06-09 22:38:53 -05:00
Most team members are part of the Ecosystem Team or Core Team. Entry into these groups is selected by Core Members only. We do not accept applications or requests for entry. Selections are made ad-hoc according to internal needs. Selections are typically announced at Community Meetings which occur quarterly.
2022-06-09 20:18:06 -04:00
## Meetings and Schedules
2022-06-09 22:38:53 -05:00
SolidJS team members organize via Discord chat and audio channels. Channels exist to manage these conversations and threads within channels are used to focus on specific topics. A number of meetings occur weekly between each group however there is no set cadence or recurring schedule. Typically attendance for team members is requested to maintain membership, however we respect and recognize OSS contributions are typically ad hoc and as can be given by our members and generous donors.
2022-06-09 20:18:06 -04:00
## Official Opportunities
2022-06-09 22:38:53 -05:00
As a growing community, Solid has an on-going need for developers, writers, designers and general thought leaders. The following is a list of openings and tasks that Core attempts to maintain often.
2022-06-09 20:18:06 -04:00
### Docs Team
2022-07-28 08:31:48 -04:00
To get involved, check out our [Contributing Guide ](https://github.com/solidjs/solid-docs-next/blob/main/CONTRIBUTING.md ) in the new docs repository!
- General/Core Docs
- Write new drafts for the new docs repo
- Work on the infrastructure for the new docs site
- Create videos, diagrams, and other multimedia content
2022-06-09 20:18:06 -04:00
- Solid Start 1.0 API
2022-07-28 08:31:48 -04:00
- Draft an initial, comprehensive set of docs for Solid Start
- This currently takes place in [this subfolder ](https://github.com/solidjs/solid-docs-next/tree/main/content/start ) on `solid-docs-next`
2022-06-09 20:18:06 -04:00
### Infrastructure Team
- Solid Site
- Help maintain the current Solid website by implementing bugs, testing and reporting issues
- Port the current website from being an SPA to Solid Start
- Website redevelopment project for 2.0
- Solid Service API
- Help implement our API service that powers solid REPL
- Test, validate and implement security and bug fixes
- Add new missing features
- Develop new Solid Docs platform and website
- Help coordinate creating MDX components
- Developer infrastructure for delivering future community documentation platform
- Solidex (our ecosystem directory)
- How maintain a list of ecosystem projects and resources (articles, podcasts etc.)
- Vet incoming PR from submissions and merge + deploy updated the directory
- Improve workflow and systems for managing Solidex
- Implement an API (via Solid Service API) to search and filter resources
- Solid Dev Tools
- We're actively looking for individuals to prototype and experiment on a set of developer tools.
### Solid Start Team
2022-06-09 22:38:53 -05:00
Solid Start is our new meta framework that focuses on enhancing Solid's DX story and general usability. Similar to SvelteKit, Next and other meta frameworks, this project is considered a primary core supported effort. Solid Start is approaching its beta release and we're looking for developers to test, validate and build on top of it. Join the #solid -start channel on Discord or the [solid-start ](https://github.com/solidjs/solid-start ) to learn more.
2022-06-09 20:18:06 -04:00
## Ecosystem Opportunities
SolidJS core members maintain a separate project called [SolidJS Community ](https://github.com/solidjs-community ). This is a large and lush ecosystem community project that encompasses a number of critical core tooling such as Solid Primitives, Solid Aria (similar to React Aria) etc.
The following are projects looking for leaders or support:
2022-06-22 05:56:57 +02:00
- [**Solid Aria** ](https://github.com/solidjs-community/solid-aria ) (lead by [@fabien-ml ](https://github.com/fabien-ml )): A port of React Aria.
- [**Solid Examples** ](https://github.com/solidjs-community/solid-examples ) (lead by [@foolswisdom ](https://github.com/mosheduminer )): A list of examples, patterns and app implementations.
- [**Solid Codemod** ](https://github.com/solidjs-community/solid-codemod ) (lead by [@trivikr ](https://github.com/trivikr )): Convert React or other libraries to Solid automatically.
- [**Solid Snippets** ](https://github.com/solidjs-community/solid-snippets ) (lead by [@thetarnav ](https://github.com/thetarnav )): VSCode snippet library.
- [**Solid DSL** ](https://github.com/solidjs-community/solid-dsl ) (lead by [@davedbase ](https://github.com/davedbase )): A project to explore enhancing JSX or other DSL options.
- [**Solid Primitives** ](https://github.com/solidjs-community/solid-primitives ) (lead by [@davedbase ](https://github.com/davedbase )): A large primitives (hooks) library.
2022-06-09 20:18:06 -04:00
Contributing to ecosystem projects is just as important as contributing to Solid core projects. As Solid grows a lush, well supported and high-quality set of packages and learning materials will benefit it's users and future viability.
## Where do I start?
If you haven't found any interesting information on this page then we encourage you to start hacking at a Solid related utility or package that does. Building useful tools for fellow OSS ecosystem and Solid users enhances the whole platform.
We can't wait to see what you build!
Solid 1.5 (#1176)
* new batching, fix #1001, fix #1062
* fix #1019, resource state
* pluggable storage on resource
* Fix createMutable to handle reactivity in case element is undefined
* Added tests
* better fixes, ssr spread improvements
* Add `has` trap for accurate `in` with stores and mutables (#1109)
* Add `has` trap for accurate `in` with stores and mutables
Fixes #1107
* Fix ?. typo
* Remove optional chaining ?.
* fix(types): fix mergeProps type when spreading array as params (#1028)
This fixes the return type of mergeProps when an array is spread as params: `mergeProps(...propsArray)`, `mergeProps(...propsArray, props)`, and `mergeProps(props1, ...propsArray, props2)`. Previously these calls would ignore the type of the array being spread and all props after the spread e.g.:
```ts
const merged = mergeProps({ a: 1 }, ...[{ b: 2 }], { c: 3 }); // { a: 1 }
```
- Allow mergeProps to be called with all manner of spread params and return the correct type.
- As a consequence of the above, mergeProps' type allows calling it with no params.
- Brought back `Simplify`, since it doesn't interfere with generics and improves readability of the result type.
- Simplified and added comments for component.ts type tests.
Additionally:
- Improved types when generic props are present.
Issues:
- This doesn't correctly type spreading multiple arrays however, since typescript doesn't allow two "rest" params: `someFn(...[1], ...["2"], 3)` is inferred as `T = [...(string | number)[], number]` and not `T = [...number[], ...string[], number]`. In this case the union of types in the array is merged into a single type, which may not be entirely accurate.
* Fix `Dynamic` types (#1116)
* Fix `Dynamic` types
* Fix `component` type
* Fix `DynamicProps`, `ComponentProps`; Add `ValidComponent`
* Fix `Dynamic` test for type fix
* Fix `Dynamic` test to use `id` instead of `title` for DOM compatibility
* Fix `component` to be required property
* fix #1112 fix built in functions on proxy failing pass through
* v1.5.0-beta.0
* cleanups on the server
* update and rework build system
* tweak turbo commands
* remove clean command
* update ci
* decrease dependency on symlink
* update lockfile
* more type issues
* fix build
* SSR performance improvement
* fix bug with ssr resolve
* bump
* Add build instructions to CONTRIBUTING (#1136)
* Add pnpm build instructions to CONTRIBUTING
* Fix Turbo link
* fix: add explicit extensions and exports fields
* errors on server while not flushed, many bug fixes
* feat(types): createResource improvements (#1130)
* feat(types): createResource improvements
- Add typable `refetching`/`refetch` with default type `unknown` for backwards compatibility.
- Remove unneeded generics.
- Refactor `createResource` parameters to reduce casting.
- Remove unneeded instances of casting, non-null assertations and `any`.
- Fix `onHydrated` type, removing `refetching`.
- Add `InitializedResource` types for overloads which define `initialValue`.
- Changed `Error` to return `never` instead of `undefined`, since reading resources in such a state throws, so the values will never be used.
- Updated docs slightly.
- Fixed a test slightly (type of an unused parameter from `string` to `unknown`).
Potential Issues:
- Adding the initialized types might slightly break userland functions. However adding them is necessary to differentiate `{ initialValue: undefined }` from omitting `initialValue`, and for cases where `T` includes `undefined` to be typed correctly.
- `store` should not need to accept `undefined` if `initialValue` is provided, but in order to make passing a generic `createSignal`-typed function work without an error, `init` and the type of the signal returned must be the same.
- In various places `undefined` can still appear if a resource errors and refetches. As such `mutate` and `store` also need to handle `undefined` correctly. This might break typing for existing `mutate` calls which are typed without `undefined`.
* test(types): add tests for createResource types
* refactor(types): fix and clean up createResource types
- Add `NoInfer` for options so that only the fetcher is used to infer the type of the resource
- Remove some unneeded casting
* feat(types): export initialized resource types
Co-authored-by: Ryan Carniato <ryansolid@gmail.com>
* simplify batching, reduce createComputed, fix #1122 enable transitions.
* bump
* remove computed from SuspenseList
* Remove computed from createProvider
* Remove a console.log (#1146)
* fixes to suspenselist
* useInitialValue on resources
* fix #1138 dialog type, fix #1147 untrack ref, fix #1151 untrack cleanup
* keyed control flow updates
* bump
* improve createSelector perf
* draft 1.5 changelog
* fix falsy check
* faster asset rendering
* children.toArray
* refactor(types): change `createStore` types for a clearer error message (#1157)
Specifically, this change targets these differences:
- Initializing a store with a generic type which is not restricted to `object` now shows `Argument of type 'T' is not assignable to parameter of type 'object | undefined'. Type 'T' is not assignable to type 'object'` instead of `Argument of type '[T]' is not assignable to parameter of type '{} extends T ? [store?: T | undefined, options?: { name?: string | undefined; } | undefined] : [store: object & T, options?: { name?: string | undefined; } | undefined]'`.
- Initializing a store with a non-generic, non-object type now shows that the expected parameter type is `object | undefined` instead of `never` (or `{} | undefiend` if trying to use `null`).
* `resource.value` and small tweaks to resources
* bump
* experimenting with nodenext
* fix
* delete resource.value, defer to further deliberation
* small naming tweaks
* bump
* update packages
* bump
* docs: add quotes to snippets (#1153)
* better option naming for resource
* add missing deps
* Update Readme (#1137)
* add missing type exports
* bump
* small updates
* untrack JSON.stringify to avoid reactive side-effects on serialization. (#1177)
* untrack JSON.stringify to avoid reactive side-effects on serialization.
* untrack JSON.stringify to avoid reactive side-effects on serialization.
* keep immdiately evaluated module code, below its indirect declared let dependencies.
Co-authored-by: Ryan Carniato <ryansolid@gmail.com>
Co-authored-by: Paolo Ricciuti <ricciutipaolo@gmail.com>
Co-authored-by: Erik Demaine <edemaine@mit.edu>
Co-authored-by: Xavier Loh <42372774+otonashixav@users.noreply.github.com>
Co-authored-by: Alexis H. Munsayac <alexis.munsayac@gmail.com>
Co-authored-by: modderme123 <modderme123@gmail.com>
Co-authored-by: Kirill Mironov <k.mironov@tinkoff.ru>
Co-authored-by: Milo <modderme123@users.noreply.github.com>
Co-authored-by: Seanghay Yath <seanghay.dev@gmail.com>
Co-authored-by: Mathieu Decaffmeyer <5883963+mathieuprog@users.noreply.github.com>
Co-authored-by: LiQuidProQuo <105608035+LiQuidProQuo@users.noreply.github.com>
2022-08-25 20:17:02 -07:00
## Building Solid
This repository uses [pnpm ](https://pnpm.io/ ) and
[Turborepo ](https://turborepo.org/ ).
If you want to build Solid from scratch, use the following steps:
2023-06-26 17:54:52 -05:00
1. `corepack enable` (use the correct version of PNPM, https://nodejs.org/api/corepack.html#enabling -the-feature)
2. `pnpm install` (install all dependencies)
3. `pnpm build`
Solid 1.5 (#1176)
* new batching, fix #1001, fix #1062
* fix #1019, resource state
* pluggable storage on resource
* Fix createMutable to handle reactivity in case element is undefined
* Added tests
* better fixes, ssr spread improvements
* Add `has` trap for accurate `in` with stores and mutables (#1109)
* Add `has` trap for accurate `in` with stores and mutables
Fixes #1107
* Fix ?. typo
* Remove optional chaining ?.
* fix(types): fix mergeProps type when spreading array as params (#1028)
This fixes the return type of mergeProps when an array is spread as params: `mergeProps(...propsArray)`, `mergeProps(...propsArray, props)`, and `mergeProps(props1, ...propsArray, props2)`. Previously these calls would ignore the type of the array being spread and all props after the spread e.g.:
```ts
const merged = mergeProps({ a: 1 }, ...[{ b: 2 }], { c: 3 }); // { a: 1 }
```
- Allow mergeProps to be called with all manner of spread params and return the correct type.
- As a consequence of the above, mergeProps' type allows calling it with no params.
- Brought back `Simplify`, since it doesn't interfere with generics and improves readability of the result type.
- Simplified and added comments for component.ts type tests.
Additionally:
- Improved types when generic props are present.
Issues:
- This doesn't correctly type spreading multiple arrays however, since typescript doesn't allow two "rest" params: `someFn(...[1], ...["2"], 3)` is inferred as `T = [...(string | number)[], number]` and not `T = [...number[], ...string[], number]`. In this case the union of types in the array is merged into a single type, which may not be entirely accurate.
* Fix `Dynamic` types (#1116)
* Fix `Dynamic` types
* Fix `component` type
* Fix `DynamicProps`, `ComponentProps`; Add `ValidComponent`
* Fix `Dynamic` test for type fix
* Fix `Dynamic` test to use `id` instead of `title` for DOM compatibility
* Fix `component` to be required property
* fix #1112 fix built in functions on proxy failing pass through
* v1.5.0-beta.0
* cleanups on the server
* update and rework build system
* tweak turbo commands
* remove clean command
* update ci
* decrease dependency on symlink
* update lockfile
* more type issues
* fix build
* SSR performance improvement
* fix bug with ssr resolve
* bump
* Add build instructions to CONTRIBUTING (#1136)
* Add pnpm build instructions to CONTRIBUTING
* Fix Turbo link
* fix: add explicit extensions and exports fields
* errors on server while not flushed, many bug fixes
* feat(types): createResource improvements (#1130)
* feat(types): createResource improvements
- Add typable `refetching`/`refetch` with default type `unknown` for backwards compatibility.
- Remove unneeded generics.
- Refactor `createResource` parameters to reduce casting.
- Remove unneeded instances of casting, non-null assertations and `any`.
- Fix `onHydrated` type, removing `refetching`.
- Add `InitializedResource` types for overloads which define `initialValue`.
- Changed `Error` to return `never` instead of `undefined`, since reading resources in such a state throws, so the values will never be used.
- Updated docs slightly.
- Fixed a test slightly (type of an unused parameter from `string` to `unknown`).
Potential Issues:
- Adding the initialized types might slightly break userland functions. However adding them is necessary to differentiate `{ initialValue: undefined }` from omitting `initialValue`, and for cases where `T` includes `undefined` to be typed correctly.
- `store` should not need to accept `undefined` if `initialValue` is provided, but in order to make passing a generic `createSignal`-typed function work without an error, `init` and the type of the signal returned must be the same.
- In various places `undefined` can still appear if a resource errors and refetches. As such `mutate` and `store` also need to handle `undefined` correctly. This might break typing for existing `mutate` calls which are typed without `undefined`.
* test(types): add tests for createResource types
* refactor(types): fix and clean up createResource types
- Add `NoInfer` for options so that only the fetcher is used to infer the type of the resource
- Remove some unneeded casting
* feat(types): export initialized resource types
Co-authored-by: Ryan Carniato <ryansolid@gmail.com>
* simplify batching, reduce createComputed, fix #1122 enable transitions.
* bump
* remove computed from SuspenseList
* Remove computed from createProvider
* Remove a console.log (#1146)
* fixes to suspenselist
* useInitialValue on resources
* fix #1138 dialog type, fix #1147 untrack ref, fix #1151 untrack cleanup
* keyed control flow updates
* bump
* improve createSelector perf
* draft 1.5 changelog
* fix falsy check
* faster asset rendering
* children.toArray
* refactor(types): change `createStore` types for a clearer error message (#1157)
Specifically, this change targets these differences:
- Initializing a store with a generic type which is not restricted to `object` now shows `Argument of type 'T' is not assignable to parameter of type 'object | undefined'. Type 'T' is not assignable to type 'object'` instead of `Argument of type '[T]' is not assignable to parameter of type '{} extends T ? [store?: T | undefined, options?: { name?: string | undefined; } | undefined] : [store: object & T, options?: { name?: string | undefined; } | undefined]'`.
- Initializing a store with a non-generic, non-object type now shows that the expected parameter type is `object | undefined` instead of `never` (or `{} | undefiend` if trying to use `null`).
* `resource.value` and small tweaks to resources
* bump
* experimenting with nodenext
* fix
* delete resource.value, defer to further deliberation
* small naming tweaks
* bump
* update packages
* bump
* docs: add quotes to snippets (#1153)
* better option naming for resource
* add missing deps
* Update Readme (#1137)
* add missing type exports
* bump
* small updates
* untrack JSON.stringify to avoid reactive side-effects on serialization. (#1177)
* untrack JSON.stringify to avoid reactive side-effects on serialization.
* untrack JSON.stringify to avoid reactive side-effects on serialization.
* keep immdiately evaluated module code, below its indirect declared let dependencies.
Co-authored-by: Ryan Carniato <ryansolid@gmail.com>
Co-authored-by: Paolo Ricciuti <ricciutipaolo@gmail.com>
Co-authored-by: Erik Demaine <edemaine@mit.edu>
Co-authored-by: Xavier Loh <42372774+otonashixav@users.noreply.github.com>
Co-authored-by: Alexis H. Munsayac <alexis.munsayac@gmail.com>
Co-authored-by: modderme123 <modderme123@gmail.com>
Co-authored-by: Kirill Mironov <k.mironov@tinkoff.ru>
Co-authored-by: Milo <modderme123@users.noreply.github.com>
Co-authored-by: Seanghay Yath <seanghay.dev@gmail.com>
Co-authored-by: Mathieu Decaffmeyer <5883963+mathieuprog@users.noreply.github.com>
Co-authored-by: LiQuidProQuo <105608035+LiQuidProQuo@users.noreply.github.com>
2022-08-25 20:17:02 -07:00
You can then run all tests via `pnpm test` .
