-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mosaic-sql: typescript implementation #274
Conversation
This commit updates mosaic-sql to use typescript. The functionality should be the same
Thanks @calvinfo! I'll take a closer look when I have some time later on. For reference, the |
Oooh got it. Okay, I can fix that. Will also fix the broken linting right now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice. Looking forward to getting this in.
I like that we can do this in steps rather than everything at once.
"forceConsistentCasingInFileNames": true, | ||
"noEmit": true, | ||
"esModuleInterop": true, | ||
"module": "CommonJS", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why commonjs? Should we use esm?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, good call! Can make changes there
packages/sql/tsconfig.json
Outdated
@@ -0,0 +1,29 @@ | |||
{ | |||
"compilerOptions": { | |||
"target": "es6", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can target esnext with our bundler, no?
packages/sql/tsconfig.json
Outdated
"allowJs": true, | ||
"skipLibCheck": true, | ||
"strict": true, | ||
"forceConsistentCasingInFileNames": true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can remove this
packages/sql/tsconfig.json
Outdated
"moduleResolution": "node", | ||
"resolveJsonModule": true, | ||
"isolatedModules": true, | ||
"jsx": "preserve", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't use jsx.
packages/sql/tsconfig.json
Outdated
"resolveJsonModule": true, | ||
"isolatedModules": true, | ||
"jsx": "preserve", | ||
"incremental": true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can use the default.
"esnext" | ||
], | ||
"allowJs": true, | ||
"skipLibCheck": true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there an error in a lib?
packages/sql/tsconfig.json
Outdated
"dom.iterable", | ||
"esnext" | ||
], | ||
"allowJs": true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have js?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not now, can remove :)
esbuild.js
Outdated
entryPoints: ['src/index.js'], | ||
target: ['esnext'], | ||
format: 'esm', | ||
entryPoints: [entrypoint], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
entryPoints: [entrypoint], | |
entryPoints: [entrypoint ?? "src/index.js"], |
then we don't need to pass it in the build calls below
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah great idea
@@ -19,16 +19,19 @@ | |||
"test": "lerna run test", | |||
"server": "nodemon packages/duckdb/bin/run-server.js", | |||
"dev": "vite", | |||
"release": "npm run test && npm run lint && lerna publish" | |||
"release": "npm run build && npm run test && npm run lint && lerna publish" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we run tests with ts-node so we don't need to build?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like we use ts-mocha so this should not be needed, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@domoritz the reason I'd added was because the mosaic-core
package relies on this library for testing. my thinking was that running the build
first would ensure that mosaic-core is referencing the dist
file, but maybe that's not right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh I see. Maybe we should run the tests everywhere with ts-mocha so that we can use ts or js. I am worried that we compiled and raw code gets out of sync and devs get confused.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, that's a solid idea. I think it'd be easy enough to add too
packages/sql/package.json
Outdated
"build": "node ../../esbuild.js mosaic-sql", | ||
"lint": "eslint src test --ext .js", | ||
"test": "mocha 'test/**/*-test.js'", | ||
"prebuild": "rimraf dist && mkdir dist && tsc", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why run tsc here? Doesn't esbuild work with ts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good call, this is from an earlier version, will remove!
One other question for both of you... in terms of linting, I think we could either do...
|
Also just followed up with a cleaned |
eslint does more than tsc so I think it's worth having both. |
Okay, |
"module": "src/index.js", | ||
"types": "dist/mosaic-sql.d.ts", | ||
"main": "dist/mosaic-sql.js", | ||
"module": "src/index.ts", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this ok? I thought we would need to always point to js files here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right, will address.
@@ -0,0 +1,161 @@ | |||
import { SQLExpression, parseSQL, sql } from "./expression"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is that any way you can mark the files as moved? Maybe rename first and commit and then change the content. It would make it easier to see the differences.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, I'm a little time-strapped for the next few days but will see if I can do some sort of rebase + fix commit log to make it easier to compare the diff.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe the easiest is to make a new branch, do the rename, commit, paste in the new files, commit again. Replace this branch.
However, now that I think about it, I wonder whether renames will be tracked correctly when we squash.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm kind of surprised that GitHub doesn't show the files as renamed. Are there so many changes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@domoritz I have a cleaned up version here: https://github.com/uwdata/mosaic/compare/main...calvinfo:calvinfo/sql/ts-2?expand=1. Lmk what you think. I'm happy to make a PR to that if you think it looks good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. It still looks like some of the files are not tracked as renamed like packages/sql/src/datetime.js.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for separating the changes. Once this works, let's merge two commits. One with all the renames, and one with the code changes. That should be good!
Tried using this in my own packages, and I think there are definitely some quirks when packaging for isomorphic use (and I think I got some of the typing wrong even though the tests pass). Definitely don't merge yet unless you want to take a better stab at updating the package.json |
@calvinfo I'd love to merge this to avoid future conflicts. I think it's okay if the types are not fully correct yet but we need clean support for having js and ts packages and an easy way to have changes to the ts sources propagate. Could I help you push this over the finish line? |
@domoritz please! Any help is super appreciated, feel free to tweak this and run with it. I can put together a list of issues I've noticed trying to pull in this package elsewhere. I'm a little swamped over the next week to make changes and don't want to block the new refactors y'all are trying to push through. |
Is it intentional to delete/create new files rather than rename with git? I feel there's a bit of git history being lost there. |
|
Closing for now since we have #355 with much better ts support. |
Thanks @domoritz! Excited to give it a shot when I pick up the project again. |
I put these partial declarations together for my own needs while waiting for #355 to land |
Hey there @jheer and @domoritz.
I took a stab at updating the
mosaic-sql
package to use typescript. Here's the implementation.My thinking for why to start with just mosaic-sql.
I tried to keep all the tests the same, though there are a few key points to bring up...
tests/cast-test.ts
: the labels are nowavg("bar")
rather thanavg(bar)
. I think this is the correct behavior, but let me know if it's not? I wasn't exactly sure what these labels were used for.package.json
formosaic-sql
exportsdist/index.js
as themain
field. this allowscore
to import regular js files in testing (though better would be to use theindex.ts
down the roadesbuild.js
is modified so that it now takes an argument. this way the typescript generation can be configured on a package-by-package basisWhat do you guys think of it? I'm not sure I have enough time to focus on some of the other packages quite yet, but wanted to get this out there as a starting point. Some of the types are quite 'loose', and I think a second pass to both simplify and unify them would be really beneficial.
I am happy to keep this in PR form for others to pick up, but wanted to get it out there as a starting point.
-Calvin