PrivateCoffee/tldraw
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1
tldraw/scripts/package.json

66 lines
1.4 KiB
JSON
Raw Normal View History

transfer-out: transfer out
2023-04-25 11:01:25 +00:00
{
"name": "@tldraw/scripts",
"description": "build scripts",
"version": "2.0.0-alpha.8",
"private": true,
"author": {
Change licenses to tldraw (#2167) This PR updates the licenses across tldraw to a bespoke tldraw license. The idea here is leverage dual licensing for revenue from companies using tldraw. The source code and its distributions are provided under a non-commercial license (tldraw) while we offer to sell / give out an alternative exclusive-use license for companies who wish to use the product for commercial purposes. - [x] Add new license - [x] Change licenses in package.jsons - [x] Update READMEs - [x] Update docs (separate repo PR) - [x] Have alternative license in hand (US) - [ ] Have alternative license in hand (UK) - [x] Have sales contract in hand (US) - [ ] Have sales contract in hand (UK) ### Change Type - [x] `major` — Breaking change
2023-12-19 10:41:01 +00:00
"name": "tldraw Inc.",
transfer-out: transfer out
2023-04-25 11:01:25 +00:00
"email": "hello@tldraw.com"
},
"homepage": "https://tldraw.dev",
Change licenses to tldraw (#2167) This PR updates the licenses across tldraw to a bespoke tldraw license. The idea here is leverage dual licensing for revenue from companies using tldraw. The source code and its distributions are provided under a non-commercial license (tldraw) while we offer to sell / give out an alternative exclusive-use license for companies who wish to use the product for commercial purposes. - [x] Add new license - [x] Change licenses in package.jsons - [x] Update READMEs - [x] Update docs (separate repo PR) - [x] Have alternative license in hand (US) - [ ] Have alternative license in hand (UK) - [x] Have sales contract in hand (US) - [ ] Have sales contract in hand (UK) ### Change Type - [x] `major` — Breaking change
2023-12-19 10:41:01 +00:00
"license": "SEE LICENSE IN LICENSE.md",
transfer-out: transfer out
2023-04-25 11:01:25 +00:00
"repository": {
"type": "git",
"url": "https://github.com/tldraw/tldraw"
},
"bugs": {
"url": "https://github.com/tldraw/tldraw/issues"
},
"keywords": [
"tldraw",
"drawing",
"app",
"development",
"whiteboard",
"canvas",
"infinite"
],
"devDependencies": {
unbrivate, dot com in (#2475) This PR moves the tldraw.com app into the public repo. ### Change Type - [x] `internal` — Any other changes that don't affect the published package[^2] --------- Co-authored-by: Dan Groshev <git@dgroshev.com> Co-authored-by: alex <alex@dytry.ch>
2024-01-16 14:38:05 +00:00
"@actions/github": "^6.0.0",
Update auto (#2952) Auto merged this PR https://github.com/intuit/auto/pull/2420/files So we can get rid of our patch file ### Change Type - [x] `internal`
2024-02-26 10:06:23 +00:00
"@auto-it/core": "^11.1.1",
unbrivate, dot com in (#2475) This PR moves the tldraw.com app into the public repo. ### Change Type - [x] `internal` — Any other changes that don't affect the published package[^2] --------- Co-authored-by: Dan Groshev <git@dgroshev.com> Co-authored-by: alex <alex@dytry.ch>
2024-01-16 14:38:05 +00:00
"@aws-sdk/client-s3": "^3.440.0",
"@aws-sdk/lib-storage": "^3.440.0",
transfer-out: transfer out
2023-04-25 11:01:25 +00:00
"@types/is-ci": "^3.0.0",
Update the project to Node 20 (#2691) ### Change Type - [x] `internal` — Any other changes that don't affect the published package
2024-01-31 16:53:40 +00:00
"@types/node": "~20.11",
[docs] Sync docs deploy with npm deploy (#3153) This PR makes it so that our docs deployment process is tied to, and mirrors, the npm deployment process. From here on: - Commits to main get deployed to staging.tldraw.dev - Commits to a special protected branch called `docs-production` get deployed to www.tldraw.dev - Whenever we create a new npm 'latest' release we reset the HEAD of docs-production to point to the tagged commit for that release. - If we make a docs change that we want to appear on tldraw.dev ASAP without waiting for the next npm release, we'll have to follow the same process as for creating a patch release i.e merge a cherry-pick PR targeting the latest release branch e.g. `v2.0.x`. This will not cause another npm patch release unless the cherry-picked changes touch source files, e.g. updating TSDoc comments. ### Change Type - [x] `docs` — Changes to the documentation, examples, or templates. - [x] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc.
2024-03-14 14:43:32 +00:00
"@types/tar": "^6.1.11",
transfer-out: transfer out
2023-04-25 11:01:25 +00:00
"@typescript-eslint/utils": "^5.59.0",
"ast-types": "^0.14.2",
"cross-fetch": "^3.1.5",
(chore) bump (#1744) Bump deps to fix build ### Change Type - [x] `dependencies`
2023-07-18 10:19:28 +00:00
"esbuild": "^0.18.4",
make CI check for yarn install warnings and fix the peer deps ones we have (#2683) - [x] `internal` — Any other changes that don't affect the published package
2024-01-30 11:41:46 +00:00
"eslint": "^8.37.0",
transfer-out: transfer out
2023-04-25 11:01:25 +00:00
"glob": "^8.0.3",
[1/2] Move docs to brivate (#1640) This PR moves the docs site to the private repo while keeping the docs content on the public repo. ### Change Type - [x] `documentation`
2023-06-23 14:23:14 +00:00
"gray-matter": "^4.0.3",
transfer-out: transfer out
2023-04-25 11:01:25 +00:00
"is-ci": "^3.0.1",
"kleur": "^4.1.5",
update lazyrepo
2023-06-05 17:32:32 +00:00
"lazyrepo": "0.0.0-alpha.27",
Add docs (#2470) This PR adds the docs app back into the tldraw monorepo. ## Deploying We'll want to update our deploy script to update the SOURCE_SHA to the newest release sha... and then deploy the docs pulling api.json files from that release. We _could_ update the docs on every push to main, but we don't have to unless something has changed. Right now there's no automated deployments from this repo. ## Side effects To make this one work, I needed to update the lock file. This might be ok (new year new lock file), and everything builds as expected, though we may want to spend some time with our scripts to be sure that things are all good. I also updated our prettier installation, which decided to add trailing commas to every generic type. Which is, I suppose, [correct behavior](https://github.com/prettier/prettier-vscode/issues/955)? But that caused diffs in every file, which is unfortunate. ### Change Type - [x] `internal` — Any other changes that don't affect the published package[^2]
2024-01-15 12:33:15 +00:00
"prettier": "^3.0.3",
transfer-out: transfer out
2023-04-25 11:01:25 +00:00
"recast": "^0.22.0",
"rimraf": "^4.4.0",
"semver": "^7.3.8",
"svgo": "^3.0.2",
bump typescript / api-extractor (#2949) This PR bumps TypeScript to 5.3.3 and API extractor. We started getting some weird behavior in CI due to different versions of the two libraries, ie where the CI api.jsons would differ from those built locally. ### Change Type - [x] `dependencies` — Changes to package dependencies[^1]
2024-02-25 11:43:17 +00:00
"typescript": "^5.3.3"
transfer-out: transfer out
2023-04-25 11:01:25 +00:00
},
"scripts": {
"lint": "yarn run -T tsx lint.ts"
Revert 09c36781 & tweak linting (#1501) This diff reverts 09c36781 and tweaks how some of our linting was working. I'm not actually sure what caused the regression that 09c36781 was fixing - it was something to do with typescript being used to transpile eslintrc.js, but that being excluded from the tsconfig for those projects. I fixed that by removing `rootDir` from those, but that revealed some other issues with files not getting ignored correctly. I fixed the ignoring issue with a change I've wanted to make to these scripts for a while: only running them on files that are actually tracked by git, instead of on everything with a relevant extension. A side effect of that is that we have to re-implement .eslintignore support ourselves, but that's very straight forward: the `ignore` package that eslint uses is very easy to include. ### Change Type - [x] `internal` — Any other changes that don't affect the published package (will not publish a new version) ### Test Plan - ### Release Notes [internal-only]
2023-06-02 10:45:51 +00:00
},
"dependencies": {
[DX] PR labels revamp (#3112) This PR switches up how PR labels are validated to allow for more freeform label tweaking in the future. Basically **huppy will now only check that your PR is labelled, it doesn't care how it's labelled**. I also updated the PR template with a new labelling scheme that we can tweak over time. So before Huppy bot had to know about the specific set of allowed labels, and now as long as the label exists you're allowed to add it. So to add a new label to the PR template, just create the label and then add an option for it in the .md file. ### Change Type - [ ] `patch` — Bug fix - [ ] `minor` — New feature - [ ] `major` — Breaking change - [ ] `dependencies` — Changes to package dependencies[^1] - [ ] `documentation` — Changes to the documentation only[^2] - [ ] `tests` — Changes to any test code only[^2] - [x] `internal` — Any other changes that don't affect the published package[^2] - [ ] I don't know
2024-03-12 14:53:57 +00:00
"@octokit/rest": "^20.0.2",
Implement new package publish process (#2996) Gonna merge in a sneaky dry run mode to test the args parsing etc ### Change Type - [ ] `patch` — Bug fix - [ ] `minor` — New feature - [ ] `major` — Breaking change - [ ] `dependencies` — Changes to package dependencies[^1] - [ ] `documentation` — Changes to the documentation only[^2] - [ ] `tests` — Changes to any test code only[^2] - [x] `internal` — Any other changes that don't affect the published package[^2] - [ ] I don't know [^1]: publishes a `patch` release, for devDependencies use `internal` [^2]: will not publish a new version ### Test Plan 1. Add a step-by-step description of how to test your PR here. 2. - [ ] Unit Tests - [ ] End to end tests ### Release Notes - Add a brief release note for your PR here.
2024-02-29 12:21:11 +00:00
"@types/minimist": "^1.2.5",
[docs] Sync docs deploy with npm deploy (#3153) This PR makes it so that our docs deployment process is tied to, and mirrors, the npm deployment process. From here on: - Commits to main get deployed to staging.tldraw.dev - Commits to a special protected branch called `docs-production` get deployed to www.tldraw.dev - Whenever we create a new npm 'latest' release we reset the HEAD of docs-production to point to the tagged commit for that release. - If we make a docs change that we want to appear on tldraw.dev ASAP without waiting for the next npm release, we'll have to follow the same process as for creating a patch release i.e merge a cherry-pick PR targeting the latest release branch e.g. `v2.0.x`. This will not cause another npm patch release unless the cherry-picked changes touch source files, e.g. updating TSDoc comments. ### Change Type - [x] `docs` — Changes to the documentation, examples, or templates. - [x] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc.
2024-03-14 14:43:32 +00:00
"@types/tmp": "^0.2.6",
unbrivate, dot com in (#2475) This PR moves the tldraw.com app into the public repo. ### Change Type - [x] `internal` — Any other changes that don't affect the published package[^2] --------- Co-authored-by: Dan Groshev <git@dgroshev.com> Co-authored-by: alex <alex@dytry.ch>
2024-01-16 14:38:05 +00:00
"ignore": "^5.2.4",
Implement new package publish process (#2996) Gonna merge in a sneaky dry run mode to test the args parsing etc ### Change Type - [ ] `patch` — Bug fix - [ ] `minor` — New feature - [ ] `major` — Breaking change - [ ] `dependencies` — Changes to package dependencies[^1] - [ ] `documentation` — Changes to the documentation only[^2] - [ ] `tests` — Changes to any test code only[^2] - [x] `internal` — Any other changes that don't affect the published package[^2] - [ ] I don't know [^1]: publishes a `patch` release, for devDependencies use `internal` [^2]: will not publish a new version ### Test Plan 1. Add a step-by-step description of how to test your PR here. 2. - [ ] Unit Tests - [ ] End to end tests ### Release Notes - Add a brief release note for your PR here.
2024-02-29 12:21:11 +00:00
"minimist": "^1.2.8",
[docs] Sync docs deploy with npm deploy (#3153) This PR makes it so that our docs deployment process is tied to, and mirrors, the npm deployment process. From here on: - Commits to main get deployed to staging.tldraw.dev - Commits to a special protected branch called `docs-production` get deployed to www.tldraw.dev - Whenever we create a new npm 'latest' release we reset the HEAD of docs-production to point to the tagged commit for that release. - If we make a docs change that we want to appear on tldraw.dev ASAP without waiting for the next npm release, we'll have to follow the same process as for creating a patch release i.e merge a cherry-pick PR targeting the latest release branch e.g. `v2.0.x`. This will not cause another npm patch release unless the cherry-picked changes touch source files, e.g. updating TSDoc comments. ### Change Type - [x] `docs` — Changes to the documentation, examples, or templates. - [x] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc.
2024-03-14 14:43:32 +00:00
"tar": "^6.2.0",
"tmp": "^0.2.3"
transfer-out: transfer out
2023-04-25 11:01:25 +00:00
}
}
Reference in a new issue Copy permalink