2020-05-20 04:50:46 +00:00
|
|
|
{
|
|
|
|
|
"name": "grist-core",
|
2022-05-19 15:00:11 +00:00
|
|
|
"version": "0.7.9",
|
2020-10-28 17:37:36 +00:00
|
|
|
"license": "Apache-2.0",
|
|
|
|
|
"description": "Grist is the evolution of spreadsheets",
|
|
|
|
|
"homepage": "https://github.com/gristlabs/grist-core",
|
|
|
|
|
"repository": "git://github.com/gristlabs/grist-core.git",
|
2020-05-20 04:50:46 +00:00
|
|
|
"scripts": {
|
(core) add machinery for self-managed flavor of Grist
Summary:
Currently, we have two ways that we deliver Grist. One is grist-core,
which has simple defaults and is relatively easy for third parties to
deploy. The second is our internal build for our SaaS, which is the
opposite. For self-managed Grist, a planned paid on-premise version
of Grist, I adopt the following approach:
* Use the `grist-core` build mechanism, extending it to accept an
overlay of extra code if present.
* Extra code is supplied in a self-contained `ext` directory, with
an `ext/app` directory that is of same structure as core `app`
and `stubs/app`.
* The `ext` directory also contains information about extra
node dependencies needed beyond that of `grist-core`.
* The `ext` directory is contained within our monorepo rather than
`grist-core` since it may contain material not under the Apache
license.
Docker builds are achieved in our monorepo by using the `--build-context`
functionality to add in `ext` during the regular `grist-core` build:
```
docker buildx build --load -t gristlabs/grist-ee --build-context=ext=../ext .
```
Incremental builds in our monorepo are achieved with the `build_core.sh` helper,
like:
```
buildtools/build_core.sh /tmp/self-managed
cd /tmp/self-managed
yarn start
```
The initial `ext` directory contains material for snapshotting to S3.
If you build the docker image as above, and have S3 access, you can
do something like:
```
docker run -p 8484:8484 --env GRIST_SESSION_SECRET=a-secret \
--env GRIST_DOCS_S3_BUCKET=grist-docs-test \
--env GRIST_DOCS_S3_PREFIX=self-managed \
-v $HOME/.aws:/root/.aws -it gristlabs/grist-ee
```
This will start a version of Grist that is like `grist-core` but with
S3 snapshots enabled. To release this code to `grist-core`, it would
just need to move from `ext/app` to `app` within core.
I tried a lot of ways of organizing self-managed Grist, and this was
what made me happiest. There are a lot of trade-offs, but here is what
I was looking for:
* Only OSS-code in grist-core. Adding mixed-license material there
feels unfair to people already working with the repo. That said,
a possible future is to move away from our private monorepo to
a public mixed-licence repo, which could have the same relationship
with grist-core as the monorepo has.
* Minimal differences between self-managed builds and one of our
existing builds, ideally hewing as close to grist-core as possible
for ease of documentation, debugging, and maintenance.
* Ideally, docker builds without copying files around (the new
`--build-context` functionality made that possible).
* Compatibility with monorepo build.
Expressing dependencies of the extra code in `ext` proved tricky to
do in a clean way. Yarn/npm fought me every step of the way - everything
related to optional dependencies was unsatisfactory in some respect.
Yarn2 is flexible but smells like it might be overreach. In the end,
organizing to install non-core dependencies one directory up from the
main build was a good simple trick that saved my bacon.
This diff gets us to the point of building `grist-ee` images conveniently,
but there isn't a public repo people can go look at to see its source. This
could be generated by taking `grist-core`, adding the `ext` directory
to it, and pushing to a distinct repository. I'm not in a hurry to do that,
since a PR to that repo would be hard to sync with our monorepo and
`grist-core`. Also, we don't have any licensing text ready for the `ext`
directory. So leaving that for future work.
Test Plan: manual
Reviewers: georgegevoian, alexmojaki
Reviewed By: georgegevoian, alexmojaki
Differential Revision: https://phab.getgrist.com/D3415
2022-05-12 15:24:48 +00:00
|
|
|
"start": "sandbox/watch.sh",
|
2020-07-27 18:57:36 +00:00
|
|
|
"install:python": "buildtools/prepare_python.sh",
|
2022-01-07 17:06:04 +00:00
|
|
|
"install:python2": "buildtools/prepare_python2.sh",
|
|
|
|
|
"install:python3": "buildtools/prepare_python3.sh",
|
(core) add machinery for self-managed flavor of Grist
Summary:
Currently, we have two ways that we deliver Grist. One is grist-core,
which has simple defaults and is relatively easy for third parties to
deploy. The second is our internal build for our SaaS, which is the
opposite. For self-managed Grist, a planned paid on-premise version
of Grist, I adopt the following approach:
* Use the `grist-core` build mechanism, extending it to accept an
overlay of extra code if present.
* Extra code is supplied in a self-contained `ext` directory, with
an `ext/app` directory that is of same structure as core `app`
and `stubs/app`.
* The `ext` directory also contains information about extra
node dependencies needed beyond that of `grist-core`.
* The `ext` directory is contained within our monorepo rather than
`grist-core` since it may contain material not under the Apache
license.
Docker builds are achieved in our monorepo by using the `--build-context`
functionality to add in `ext` during the regular `grist-core` build:
```
docker buildx build --load -t gristlabs/grist-ee --build-context=ext=../ext .
```
Incremental builds in our monorepo are achieved with the `build_core.sh` helper,
like:
```
buildtools/build_core.sh /tmp/self-managed
cd /tmp/self-managed
yarn start
```
The initial `ext` directory contains material for snapshotting to S3.
If you build the docker image as above, and have S3 access, you can
do something like:
```
docker run -p 8484:8484 --env GRIST_SESSION_SECRET=a-secret \
--env GRIST_DOCS_S3_BUCKET=grist-docs-test \
--env GRIST_DOCS_S3_PREFIX=self-managed \
-v $HOME/.aws:/root/.aws -it gristlabs/grist-ee
```
This will start a version of Grist that is like `grist-core` but with
S3 snapshots enabled. To release this code to `grist-core`, it would
just need to move from `ext/app` to `app` within core.
I tried a lot of ways of organizing self-managed Grist, and this was
what made me happiest. There are a lot of trade-offs, but here is what
I was looking for:
* Only OSS-code in grist-core. Adding mixed-license material there
feels unfair to people already working with the repo. That said,
a possible future is to move away from our private monorepo to
a public mixed-licence repo, which could have the same relationship
with grist-core as the monorepo has.
* Minimal differences between self-managed builds and one of our
existing builds, ideally hewing as close to grist-core as possible
for ease of documentation, debugging, and maintenance.
* Ideally, docker builds without copying files around (the new
`--build-context` functionality made that possible).
* Compatibility with monorepo build.
Expressing dependencies of the extra code in `ext` proved tricky to
do in a clean way. Yarn/npm fought me every step of the way - everything
related to optional dependencies was unsatisfactory in some respect.
Yarn2 is flexible but smells like it might be overreach. In the end,
organizing to install non-core dependencies one directory up from the
main build was a good simple trick that saved my bacon.
This diff gets us to the point of building `grist-ee` images conveniently,
but there isn't a public repo people can go look at to see its source. This
could be generated by taking `grist-core`, adding the `ext` directory
to it, and pushing to a distinct repository. I'm not in a hurry to do that,
since a PR to that repo would be hard to sync with our monorepo and
`grist-core`. Also, we don't have any licensing text ready for the `ext`
directory. So leaving that for future work.
Test Plan: manual
Reviewers: georgegevoian, alexmojaki
Reviewed By: georgegevoian, alexmojaki
Differential Revision: https://phab.getgrist.com/D3415
2022-05-12 15:24:48 +00:00
|
|
|
"build:prod": "buildtools/build.sh",
|
|
|
|
|
"start:prod": "sandbox/run.sh",
|
2022-08-18 21:08:39 +00:00
|
|
|
"test": "GRIST_SESSION_COOKIE=grist_test_cookie GRIST_TEST_LOGIN=1 TEST_SUPPORT_API_KEY=api_key_for_support TEST_CLEAN_DATABASE=true NODE_PATH=_build:_build/stubs:_build/ext mocha -g ${GREP_TESTS:-''} _build/test/common/*.js _build/test/client/*.js _build/test/nbrowser/*.js _build/test/server/**/*.js _build/test/gen-server/**/*.js",
|
|
|
|
|
"test:client": "GRIST_SESSION_COOKIE=grist_test_cookie NODE_PATH=_build:_build/stubs:_build/ext mocha _build/test/client/**/*.js",
|
|
|
|
|
"test:common": "GRIST_SESSION_COOKIE=grist_test_cookie NODE_PATH=_build:_build/stubs:_build/ext mocha _build/test/common/**/*.js",
|
(core) add machinery for self-managed flavor of Grist
Summary:
Currently, we have two ways that we deliver Grist. One is grist-core,
which has simple defaults and is relatively easy for third parties to
deploy. The second is our internal build for our SaaS, which is the
opposite. For self-managed Grist, a planned paid on-premise version
of Grist, I adopt the following approach:
* Use the `grist-core` build mechanism, extending it to accept an
overlay of extra code if present.
* Extra code is supplied in a self-contained `ext` directory, with
an `ext/app` directory that is of same structure as core `app`
and `stubs/app`.
* The `ext` directory also contains information about extra
node dependencies needed beyond that of `grist-core`.
* The `ext` directory is contained within our monorepo rather than
`grist-core` since it may contain material not under the Apache
license.
Docker builds are achieved in our monorepo by using the `--build-context`
functionality to add in `ext` during the regular `grist-core` build:
```
docker buildx build --load -t gristlabs/grist-ee --build-context=ext=../ext .
```
Incremental builds in our monorepo are achieved with the `build_core.sh` helper,
like:
```
buildtools/build_core.sh /tmp/self-managed
cd /tmp/self-managed
yarn start
```
The initial `ext` directory contains material for snapshotting to S3.
If you build the docker image as above, and have S3 access, you can
do something like:
```
docker run -p 8484:8484 --env GRIST_SESSION_SECRET=a-secret \
--env GRIST_DOCS_S3_BUCKET=grist-docs-test \
--env GRIST_DOCS_S3_PREFIX=self-managed \
-v $HOME/.aws:/root/.aws -it gristlabs/grist-ee
```
This will start a version of Grist that is like `grist-core` but with
S3 snapshots enabled. To release this code to `grist-core`, it would
just need to move from `ext/app` to `app` within core.
I tried a lot of ways of organizing self-managed Grist, and this was
what made me happiest. There are a lot of trade-offs, but here is what
I was looking for:
* Only OSS-code in grist-core. Adding mixed-license material there
feels unfair to people already working with the repo. That said,
a possible future is to move away from our private monorepo to
a public mixed-licence repo, which could have the same relationship
with grist-core as the monorepo has.
* Minimal differences between self-managed builds and one of our
existing builds, ideally hewing as close to grist-core as possible
for ease of documentation, debugging, and maintenance.
* Ideally, docker builds without copying files around (the new
`--build-context` functionality made that possible).
* Compatibility with monorepo build.
Expressing dependencies of the extra code in `ext` proved tricky to
do in a clean way. Yarn/npm fought me every step of the way - everything
related to optional dependencies was unsatisfactory in some respect.
Yarn2 is flexible but smells like it might be overreach. In the end,
organizing to install non-core dependencies one directory up from the
main build was a good simple trick that saved my bacon.
This diff gets us to the point of building `grist-ee` images conveniently,
but there isn't a public repo people can go look at to see its source. This
could be generated by taking `grist-core`, adding the `ext` directory
to it, and pushing to a distinct repository. I'm not in a hurry to do that,
since a PR to that repo would be hard to sync with our monorepo and
`grist-core`. Also, we don't have any licensing text ready for the `ext`
directory. So leaving that for future work.
Test Plan: manual
Reviewers: georgegevoian, alexmojaki
Reviewed By: georgegevoian, alexmojaki
Differential Revision: https://phab.getgrist.com/D3415
2022-05-12 15:24:48 +00:00
|
|
|
"test:server": "GRIST_SESSION_COOKIE=grist_test_cookie NODE_PATH=_build:_build/stubs:_build/ext mocha _build/test/server/**/*.js _build/test/gen-server/**/*.js",
|
|
|
|
|
"test:smoke": "NODE_PATH=_build:_build/stubs:_build/ext mocha _build/test/nbrowser/Smoke.js",
|
(core) add a `yarn run cli` tool, and add a `sqlite gristify` option
Summary:
This adds rudimentary support for opening certain SQLite files in Grist.
If you have a file such as `landing.db` in Grist, you can convert it to Grist format by doing (either in monorepo or grist-core):
```
yarn run cli -h
yarn run cli sqlite -h
yarn run cli sqlite gristify landing.db
```
The file is now openable by Grist. To actually do so with the regular Grist server, you'll need to either import it, or convert some doc you don't care about in the `samples/` directory to be a soft link to it (and then force a reload).
This implementation is a rudimentary experiment. Here are some awkwardnesses:
* Only tables that happen to have a column called `id`, and where the column happens to be an integer, can be opened directly with Grist as it is today. That could be generalized, but it looked more than a Gristathon's worth of work, so I instead used SQLite views.
* Grist will handle tables that start with an uncapitalized letter a bit erratically. You can successfully add columns, for example, but removing them will cause sadness - Grist will rename the table in a confused way.
* I didn't attempt to deal with column names with spaces etc (though views could deal with those).
* I haven't tried to do any fancy type mapping.
* Columns with constraints can make adding new rows impossible in Grist, since Grist requires that a row can be added with just a single cell set.
Test Plan: added small test
Reviewers: georgegevoian
Reviewed By: georgegevoian
Differential Revision: https://phab.getgrist.com/D3502
2022-07-14 09:32:06 +00:00
|
|
|
"test:docker": "./test/test_under_docker.sh",
|
|
|
|
|
"cli": "NODE_PATH=_build:_build/stubs:_build/ext node _build/app/server/companion.js"
|
2020-05-20 04:50:46 +00:00
|
|
|
},
|
2020-10-28 17:37:36 +00:00
|
|
|
"keywords": [
|
|
|
|
|
"grist",
|
|
|
|
|
"spreadsheet",
|
|
|
|
|
"database"
|
|
|
|
|
],
|
|
|
|
|
"author": {
|
|
|
|
|
"name": "Grist Labs Inc.",
|
|
|
|
|
"email": "info@getgrist.com"
|
|
|
|
|
},
|
|
|
|
|
"private": false,
|
2020-05-20 04:50:46 +00:00
|
|
|
"devDependencies": {
|
2021-08-26 21:06:55 +00:00
|
|
|
"@types/accept-language-parser": "1.5.2",
|
2020-07-21 13:20:51 +00:00
|
|
|
"@types/backbone": "1.3.43",
|
2021-04-02 23:11:27 +00:00
|
|
|
"@types/chai": "4.1.7",
|
|
|
|
|
"@types/chai-as-promised": "7.1.0",
|
2020-07-21 13:20:51 +00:00
|
|
|
"@types/content-disposition": "0.5.2",
|
2020-10-02 15:10:00 +00:00
|
|
|
"@types/diff-match-patch": "1.0.32",
|
2020-07-21 13:20:51 +00:00
|
|
|
"@types/double-ended-queue": "2.1.0",
|
|
|
|
|
"@types/express": "4.16.0",
|
2021-04-02 23:11:27 +00:00
|
|
|
"@types/form-data": "2.2.1",
|
2020-07-21 13:20:51 +00:00
|
|
|
"@types/fs-extra": "5.0.4",
|
|
|
|
|
"@types/image-size": "0.0.29",
|
|
|
|
|
"@types/js-yaml": "3.11.2",
|
2022-08-18 21:08:39 +00:00
|
|
|
"@types/jsdom": "16.2.14",
|
2022-07-27 20:20:14 +00:00
|
|
|
"@types/jsesc": "3.0.1",
|
2022-07-19 15:39:49 +00:00
|
|
|
"@types/jsonwebtoken": "7.2.8",
|
2020-07-21 13:20:51 +00:00
|
|
|
"@types/lodash": "4.14.117",
|
2021-10-01 13:45:27 +00:00
|
|
|
"@types/lru-cache": "5.1.1",
|
2021-04-02 23:11:27 +00:00
|
|
|
"@types/mime-types": "2.1.0",
|
|
|
|
|
"@types/mocha": "5.2.5",
|
2020-07-21 13:20:51 +00:00
|
|
|
"@types/moment-timezone": "0.5.9",
|
(core) Speed up and upgrade build.
Summary:
- Upgrades to build-related packages:
- Upgrade typescript, related libraries and typings.
- Upgrade webpack, eslint; add tsc-watch, node-dev, eslint_d.
- Build organization changes:
- Build webpack from original typescript, transpiling only; with errors still
reported by a background tsc watching process.
- Typescript-related changes:
- Reduce imports of AWS dependencies (very noticeable speedup)
- Avoid auto-loading global @types
- Client code is now built with isolatedModules flag (for safe transpilation)
- Use allowJs to avoid copying JS files manually.
- Linting changes
- Enhance Arcanist ESLintLinter to run before/after commands, and set up to use eslint_d
- Update eslint config, and include .eslintignore to avoid linting generated files.
- Include a bunch of eslint-prompted and eslint-generated fixes
- Add no-unused-expression rule to eslint, and fix a few warnings about it
- Other items:
- Refactor cssInput to avoid circular dependency
- Remove a bit of unused code, libraries, dependencies
Test Plan: No behavior changes, all existing tests pass. There are 30 tests fewer reported because `test_gpath.py` was removed (it's been unused for years)
Reviewers: paulfitz
Reviewed By: paulfitz
Subscribers: paulfitz
Differential Revision: https://phab.getgrist.com/D3498
2022-06-27 20:09:41 +00:00
|
|
|
"@types/node": "^14",
|
2020-07-21 13:20:51 +00:00
|
|
|
"@types/node-fetch": "2.1.2",
|
|
|
|
|
"@types/pidusage": "2.0.1",
|
2022-08-02 14:54:54 +00:00
|
|
|
"@types/plotly.js": "2.12.1",
|
2022-01-07 18:11:52 +00:00
|
|
|
"@types/qrcode": "1.4.2",
|
2020-07-21 13:20:51 +00:00
|
|
|
"@types/redlock": "3.0.2",
|
2021-08-16 15:11:17 +00:00
|
|
|
"@types/saml2-js": "2.0.1",
|
2021-04-02 23:11:27 +00:00
|
|
|
"@types/selenium-webdriver": "4.0.0",
|
2022-05-18 10:25:14 +00:00
|
|
|
"@types/sinon": "5.0.5",
|
2020-07-21 13:20:51 +00:00
|
|
|
"@types/sqlite3": "3.1.6",
|
|
|
|
|
"@types/tmp": "0.0.33",
|
|
|
|
|
"@types/uuid": "3.4.4",
|
(core) support python3 in grist-core, and running engine via docker and/or gvisor
Summary:
* Moves essential plugins to grist-core, so that basic imports (e.g. csv) work.
* Adds support for a `GRIST_SANDBOX_FLAVOR` flag that can systematically override how the data engine is run.
- `GRIST_SANDBOX_FLAVOR=pynbox` is "classic" nacl-based sandbox.
- `GRIST_SANDBOX_FLAVOR=docker` runs engines in individual docker containers. It requires an image specified in `sandbox/docker` (alternative images can be named with `GRIST_SANDBOX` flag - need to contain python and engine requirements). It is a simple reference implementation for sandboxing.
- `GRIST_SANDBOX_FLAVOR=unsandboxed` runs whatever local version of python is specified by a `GRIST_SANDBOX` flag directly, with no sandboxing. Engine requirements must be installed, so an absolute path to a python executable in a virtualenv is easiest to manage.
- `GRIST_SANDBOX_FLAVOR=gvisor` runs the data engine via gvisor's runsc. Experimental, with implementation not included in grist-core. Since gvisor runs on Linux only, this flavor supports wrapping the sandboxes in a single shared docker container.
* Tweaks some recent express query parameter code to work in grist-core, which has a slightly different version of express (smoke test doesn't catch this since in Jenkins core is built within a workspace that has node_modules, and wires get crossed - in a dev environment the problem on master can be seen by doing `buildtools/build_core.sh /tmp/any_path_outside_grist`).
The new sandbox options do not have tests yet, nor does this they change the behavior of grist servers today. They are there to clean up and consolidate a collection of patches I've been using that were getting cumbersome, and make it easier to run experiments.
I haven't looked closely at imports beyond core.
Test Plan: tested manually against regular grist and grist-core, including imports
Reviewers: alexmojaki, dsagal
Reviewed By: alexmojaki
Differential Revision: https://phab.getgrist.com/D2942
2021-07-27 23:43:21 +00:00
|
|
|
"@types/which": "2.0.1",
|
2022-06-04 04:12:30 +00:00
|
|
|
"@types/ws": "^6",
|
2022-03-24 17:11:26 +00:00
|
|
|
"app-module-path": "2.2.0",
|
2020-10-02 15:10:00 +00:00
|
|
|
"catw": "1.0.1",
|
2021-04-02 23:11:27 +00:00
|
|
|
"chai": "4.2.0",
|
|
|
|
|
"chai-as-promised": "7.1.1",
|
2022-08-18 21:08:39 +00:00
|
|
|
"chance": "1.0.16",
|
(core) Speed up and upgrade build.
Summary:
- Upgrades to build-related packages:
- Upgrade typescript, related libraries and typings.
- Upgrade webpack, eslint; add tsc-watch, node-dev, eslint_d.
- Build organization changes:
- Build webpack from original typescript, transpiling only; with errors still
reported by a background tsc watching process.
- Typescript-related changes:
- Reduce imports of AWS dependencies (very noticeable speedup)
- Avoid auto-loading global @types
- Client code is now built with isolatedModules flag (for safe transpilation)
- Use allowJs to avoid copying JS files manually.
- Linting changes
- Enhance Arcanist ESLintLinter to run before/after commands, and set up to use eslint_d
- Update eslint config, and include .eslintignore to avoid linting generated files.
- Include a bunch of eslint-prompted and eslint-generated fixes
- Add no-unused-expression rule to eslint, and fix a few warnings about it
- Other items:
- Refactor cssInput to avoid circular dependency
- Remove a bit of unused code, libraries, dependencies
Test Plan: No behavior changes, all existing tests pass. There are 30 tests fewer reported because `test_gpath.py` was removed (it's been unused for years)
Reviewers: paulfitz
Reviewed By: paulfitz
Subscribers: paulfitz
Differential Revision: https://phab.getgrist.com/D3498
2022-06-27 20:09:41 +00:00
|
|
|
"esbuild-loader": "2.19.0",
|
2022-08-18 21:08:39 +00:00
|
|
|
"jsdom": "13.0.0",
|
2021-04-02 23:11:27 +00:00
|
|
|
"mocha": "5.2.0",
|
2021-07-12 16:10:04 +00:00
|
|
|
"mocha-webdriver": "0.2.9",
|
2020-05-20 04:50:46 +00:00
|
|
|
"moment-locales-webpack-plugin": "^1.2.0",
|
|
|
|
|
"nodemon": "^2.0.4",
|
2022-04-01 21:31:24 +00:00
|
|
|
"otplib": "12.0.1",
|
2021-04-02 23:11:27 +00:00
|
|
|
"selenium-webdriver": "3.6.0",
|
2022-05-18 10:25:14 +00:00
|
|
|
"sinon": "7.1.1",
|
2020-05-20 04:50:46 +00:00
|
|
|
"source-map-loader": "^0.2.4",
|
2021-07-19 14:44:16 +00:00
|
|
|
"tmp-promise": "1.0.5",
|
2022-09-05 08:24:34 +00:00
|
|
|
"ts-interface-builder": "0.3.2",
|
(core) Speed up and upgrade build.
Summary:
- Upgrades to build-related packages:
- Upgrade typescript, related libraries and typings.
- Upgrade webpack, eslint; add tsc-watch, node-dev, eslint_d.
- Build organization changes:
- Build webpack from original typescript, transpiling only; with errors still
reported by a background tsc watching process.
- Typescript-related changes:
- Reduce imports of AWS dependencies (very noticeable speedup)
- Avoid auto-loading global @types
- Client code is now built with isolatedModules flag (for safe transpilation)
- Use allowJs to avoid copying JS files manually.
- Linting changes
- Enhance Arcanist ESLintLinter to run before/after commands, and set up to use eslint_d
- Update eslint config, and include .eslintignore to avoid linting generated files.
- Include a bunch of eslint-prompted and eslint-generated fixes
- Add no-unused-expression rule to eslint, and fix a few warnings about it
- Other items:
- Refactor cssInput to avoid circular dependency
- Remove a bit of unused code, libraries, dependencies
Test Plan: No behavior changes, all existing tests pass. There are 30 tests fewer reported because `test_gpath.py` was removed (it's been unused for years)
Reviewers: paulfitz
Reviewed By: paulfitz
Subscribers: paulfitz
Differential Revision: https://phab.getgrist.com/D3498
2022-06-27 20:09:41 +00:00
|
|
|
"typescript": "4.7.4",
|
|
|
|
|
"webpack": "5.73.0",
|
|
|
|
|
"webpack-cli": "4.10.0",
|
2021-04-26 22:49:02 +00:00
|
|
|
"why-is-node-running": "2.0.3"
|
2020-05-20 04:50:46 +00:00
|
|
|
},
|
|
|
|
|
"dependencies": {
|
2021-07-21 08:46:03 +00:00
|
|
|
"@googleapis/drive": "0.3.1",
|
|
|
|
|
"@googleapis/oauth2": "0.2.0",
|
2022-02-21 22:24:17 +00:00
|
|
|
"@gristlabs/connect-sqlite3": "0.9.11-grist.4",
|
2020-07-21 13:20:51 +00:00
|
|
|
"@gristlabs/express-session": "1.17.0",
|
2022-02-21 14:45:17 +00:00
|
|
|
"@gristlabs/moment-guess": "1.2.4-grist.1",
|
2020-07-21 13:20:51 +00:00
|
|
|
"@gristlabs/pidusage": "2.0.17",
|
2022-03-11 20:24:26 +00:00
|
|
|
"@gristlabs/sqlite3": "4.1.1-grist.6",
|
2020-10-02 15:10:00 +00:00
|
|
|
"@popperjs/core": "2.3.3",
|
2021-08-26 21:06:55 +00:00
|
|
|
"accept-language-parser": "1.5.0",
|
2020-10-30 16:53:23 +00:00
|
|
|
"async-mutex": "0.2.4",
|
2022-09-07 15:28:53 +00:00
|
|
|
"axios": "0.21.2",
|
2020-07-21 13:20:51 +00:00
|
|
|
"backbone": "1.3.3",
|
2020-10-02 15:10:00 +00:00
|
|
|
"bootstrap": "3.3.5",
|
|
|
|
|
"bootstrap-datepicker": "1.9.0",
|
|
|
|
|
"bowser": "2.7.0",
|
|
|
|
|
"brace": "0.11.1",
|
2020-07-21 13:20:51 +00:00
|
|
|
"collect-js-deps": "^0.1.1",
|
2022-08-08 13:32:50 +00:00
|
|
|
"color-convert": "2.0.1",
|
(core) add a `yarn run cli` tool, and add a `sqlite gristify` option
Summary:
This adds rudimentary support for opening certain SQLite files in Grist.
If you have a file such as `landing.db` in Grist, you can convert it to Grist format by doing (either in monorepo or grist-core):
```
yarn run cli -h
yarn run cli sqlite -h
yarn run cli sqlite gristify landing.db
```
The file is now openable by Grist. To actually do so with the regular Grist server, you'll need to either import it, or convert some doc you don't care about in the `samples/` directory to be a soft link to it (and then force a reload).
This implementation is a rudimentary experiment. Here are some awkwardnesses:
* Only tables that happen to have a column called `id`, and where the column happens to be an integer, can be opened directly with Grist as it is today. That could be generalized, but it looked more than a Gristathon's worth of work, so I instead used SQLite views.
* Grist will handle tables that start with an uncapitalized letter a bit erratically. You can successfully add columns, for example, but removing them will cause sadness - Grist will rename the table in a confused way.
* I didn't attempt to deal with column names with spaces etc (though views could deal with those).
* I haven't tried to do any fancy type mapping.
* Columns with constraints can make adding new rows impossible in Grist, since Grist requires that a row can be added with just a single cell set.
Test Plan: added small test
Reviewers: georgegevoian
Reviewed By: georgegevoian
Differential Revision: https://phab.getgrist.com/D3502
2022-07-14 09:32:06 +00:00
|
|
|
"commander": "9.3.0",
|
2020-10-02 15:10:00 +00:00
|
|
|
"components-jqueryui": "1.12.1",
|
2022-04-12 20:39:56 +00:00
|
|
|
"connect-redis": "3.4.0",
|
2022-05-18 10:25:14 +00:00
|
|
|
"cookie": "0.5.0",
|
2020-07-21 13:20:51 +00:00
|
|
|
"cookie-parser": "1.4.3",
|
|
|
|
|
"csv": "4.0.0",
|
2020-10-02 15:10:00 +00:00
|
|
|
"diff-match-patch": "1.0.5",
|
2020-07-21 13:20:51 +00:00
|
|
|
"double-ended-queue": "2.1.0-0",
|
2020-10-02 15:10:00 +00:00
|
|
|
"electron": "3.0.7",
|
2021-07-21 08:46:03 +00:00
|
|
|
"exceljs": "4.2.1",
|
2020-07-21 13:20:51 +00:00
|
|
|
"express": "4.16.4",
|
|
|
|
|
"file-type": "14.1.4",
|
|
|
|
|
"fs-extra": "7.0.0",
|
2021-10-15 09:31:13 +00:00
|
|
|
"grain-rpc": "0.1.7",
|
(core) move more tests to grist-core
Summary:
* Tie build and run-time docker base images to a consistent version (buster)
* Extend the test login system activated by GRIST_TEST_LOGIN to ease porting tests that currently rely on cognito (many)
* Make org resets work in absence of billing endpoints
* When in-memory session caches are used, add missing invalidation steps
* Pass org information through sign-ups/sign-ins more carefully
* For CORS, explicitly trust GRIST_HOST origin when set
* Move some fixtures and tests to core, focussing on tests that cover existing failures or are in the set of tests run on deployments
* Retain regular `test` target to run the test suite directly, without docker
* Add a `test:smoke` target to run a single simple test without `GRIST_TEST_LOGIN` activated
* Add a `test:docker` target to run the tests against a grist-core docker image - since tests rely on certain fixture teams/docs, added `TEST_SUPPORT_API_KEY` and `TEST_ADD_SAMPLES` flags to ease porting
The tests ported were `nbrowser` tests: `ActionLog.ts` (the first test I tend to port to anything, out of habit), `Fork.ts` (exercises a lot of doc creation paths), `HomeIntro.ts` (a lot of DocMenu exercise), and `DuplicateDocument.ts` (covers a feature known to be failing prior to this diff, the CORS tweak resolves it).
Test Plan: Manually tested via `buildtools/build_core.sh`. In follow up, I want to add running the `test:docker` target in grist-core's workflows. In jenkins, only the smoke test is run. There'd be an argument for running all tests, but they include particularly slow tests, and are duplicates of tests already run (in different configuration admittedly), so I'd like to try first just using them in grist-core to gate updates to any packaged version of Grist (the docker image currently).
Reviewers: alexmojaki
Reviewed By: alexmojaki
Subscribers: alexmojaki
Differential Revision: https://phab.getgrist.com/D3176
2021-12-10 22:42:54 +00:00
|
|
|
"grainjs": "1.0.2",
|
2022-09-07 15:28:53 +00:00
|
|
|
"handlebars": "4.7.7",
|
2021-04-02 23:11:27 +00:00
|
|
|
"highlight.js": "9.13.1",
|
2022-06-17 18:49:18 +00:00
|
|
|
"http-proxy-agent": "5.0.0",
|
|
|
|
|
"https-proxy-agent": "5.0.1",
|
2020-10-26 14:45:31 +00:00
|
|
|
"i18n-iso-countries": "6.1.0",
|
2020-07-21 13:20:51 +00:00
|
|
|
"image-size": "0.6.3",
|
2022-09-07 15:28:53 +00:00
|
|
|
"jquery": "3.5.0",
|
2020-07-21 13:20:51 +00:00
|
|
|
"js-yaml": "3.12.0",
|
2022-07-27 20:20:14 +00:00
|
|
|
"jsesc": "3.0.2",
|
2022-07-19 15:39:49 +00:00
|
|
|
"jsonwebtoken": "8.3.0",
|
2020-07-21 13:20:51 +00:00
|
|
|
"knockout": "3.5.0",
|
2021-08-26 21:06:55 +00:00
|
|
|
"locale-currency": "0.0.2",
|
2020-07-21 13:20:51 +00:00
|
|
|
"lodash": "4.17.15",
|
2022-09-07 15:28:53 +00:00
|
|
|
"moment": "2.29.4",
|
|
|
|
|
"moment-timezone": "0.5.35",
|
2020-07-21 13:20:51 +00:00
|
|
|
"morgan": "1.9.1",
|
2020-10-02 15:10:00 +00:00
|
|
|
"mousetrap": "1.6.2",
|
2021-05-13 02:06:19 +00:00
|
|
|
"multiparty": "4.2.2",
|
2022-09-07 15:28:53 +00:00
|
|
|
"node-fetch": "2.6.7",
|
2022-05-18 19:43:51 +00:00
|
|
|
"pg": "8.6.0",
|
2022-08-02 14:54:54 +00:00
|
|
|
"plotly.js-basic-dist": "2.13.2",
|
2020-10-02 15:10:00 +00:00
|
|
|
"popper-max-size-modifier": "0.2.0",
|
|
|
|
|
"popweasel": "0.1.18",
|
2022-01-07 18:11:52 +00:00
|
|
|
"qrcode": "1.5.0",
|
2020-10-02 15:10:00 +00:00
|
|
|
"randomcolor": "0.5.3",
|
2022-09-07 15:28:53 +00:00
|
|
|
"redis": "3.1.1",
|
2020-07-21 13:20:51 +00:00
|
|
|
"redlock": "3.1.2",
|
2021-08-16 15:11:17 +00:00
|
|
|
"saml2-js": "2.0.3",
|
2020-07-21 13:20:51 +00:00
|
|
|
"short-uuid": "3.1.1",
|
|
|
|
|
"tmp": "0.0.33",
|
2021-10-15 09:31:13 +00:00
|
|
|
"ts-interface-checker": "1.0.2",
|
2022-08-31 16:30:16 +00:00
|
|
|
"typeorm": "0.3.9",
|
2022-08-18 21:08:39 +00:00
|
|
|
"underscore": "1.9.1",
|
2020-07-21 13:20:51 +00:00
|
|
|
"uuid": "3.3.2",
|
2021-05-10 18:44:10 +00:00
|
|
|
"winston": "2.4.5",
|
2020-07-21 13:20:51 +00:00
|
|
|
"ws": "6.1.0"
|
2020-10-02 15:10:00 +00:00
|
|
|
},
|
|
|
|
|
"resolutions": {
|
2022-09-07 15:28:53 +00:00
|
|
|
"jquery": "3.5.0",
|
2021-10-15 09:31:13 +00:00
|
|
|
"ts-interface-checker": "1.0.2"
|
2020-05-20 04:50:46 +00:00
|
|
|
}
|
|
|
|
|
}
|
