Skip to content
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

Closed
wants to merge 7 commits into from

Conversation

calvinfo
Copy link

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.

  • as the 'base' for more of the stuff in core, this one seemed like a good place to start
  • it seemed like the most well-tested of the packages

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 now avg("bar") rather than avg(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.
  • the package.json for mosaic-sql exports dist/index.js as the main field. this allows core to import regular js files in testing (though better would be to use the index.ts down the road
  • esbuild.js is modified so that it now takes an argument. this way the typescript generation can be configured on a package-by-package basis

What 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

This commit updates mosaic-sql to use typescript. The functionality
should be the same
@jheer
Copy link
Member

jheer commented Jan 24, 2024

Thanks @calvinfo! I'll take a closer look when I have some time later on. For reference, the label is a text string that can be used by visualization code to generate human-friendly labels (e.g., as part of axis titles). FWIW the lack of quotation marks was intentional.

@calvinfo
Copy link
Author

Oooh got it. Okay, I can fix that. Will also fix the broken linting right now.

Copy link
Member

@domoritz domoritz left a 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",
Copy link
Member

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?

Copy link
Author

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

@@ -0,0 +1,29 @@
{
"compilerOptions": {
"target": "es6",
Copy link
Member

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?

"allowJs": true,
"skipLibCheck": true,
"strict": true,
"forceConsistentCasingInFileNames": true,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can remove this

"moduleResolution": "node",
"resolveJsonModule": true,
"isolatedModules": true,
"jsx": "preserve",
Copy link
Member

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.

"resolveJsonModule": true,
"isolatedModules": true,
"jsx": "preserve",
"incremental": true,
Copy link
Member

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,
Copy link
Member

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?

"dom.iterable",
"esnext"
],
"allowJs": true,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have js?

Copy link
Author

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],
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
entryPoints: [entrypoint],
entryPoints: [entrypoint ?? "src/index.js"],

then we don't need to pass it in the build calls below

Copy link
Author

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"
Copy link
Member

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?

Copy link
Member

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?

Copy link
Author

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?

Copy link
Member

@domoritz domoritz Jan 24, 2024

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.

Copy link
Author

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

"build": "node ../../esbuild.js mosaic-sql",
"lint": "eslint src test --ext .js",
"test": "mocha 'test/**/*-test.js'",
"prebuild": "rimraf dist && mkdir dist && tsc",
Copy link
Member

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?

Copy link
Author

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!

@calvinfo
Copy link
Author

One other question for both of you... in terms of linting, I think we could either do...

  1. add @typescript-eslint to the .eslint config for this repo. using the recommend plugins means getting rid of all any types (or ignoring them manually). I've considered adding an Expression type which would be type Expression = SQLExpression | Ref | Param | string; which I think would take care of the majority of cases. I want to ensure I'm understanding the typing properly... does that seem right?
  2. remove linting for this package for the moment, since the typescript compilation will catch any obvious mistakes.

@calvinfo
Copy link
Author

Also just followed up with a cleaned tsconfig. Let me know what you think.

@domoritz
Copy link
Member

eslint does more than tsc so I think it's worth having both.

@calvinfo
Copy link
Author

Okay, label now works as desired (regarding the above comment) and npm run lint is fixed too. For the moment it warns on any types, but I think we can narrow those down over time. I could definitely benefit from both your thoughts on the typing side when it comes to making them much tighter and more intuitive.

"module": "src/index.js",
"types": "dist/mosaic-sql.d.ts",
"main": "dist/mosaic-sql.js",
"module": "src/index.ts",
Copy link
Member

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.

Copy link
Author

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";
Copy link
Member

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.

Copy link
Author

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.

Copy link
Member

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.

Copy link
Member

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?

Copy link
Author

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.

Copy link
Member

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, not sure what to tell you there. I separated it out this time into two explicit rename commits (no functionality change)

37a2b92
bc4d19c

In the case of datetime.js, I think a high enough percentage of the lines changed to trigger a "re-write" vs a "rename" in the github UI.

Copy link
Member

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!

@calvinfo
Copy link
Author

calvinfo commented Feb 1, 2024

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

@domoritz
Copy link
Member

domoritz commented Feb 8, 2024

@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?

@calvinfo
Copy link
Author

calvinfo commented Feb 9, 2024

@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.

@eknowles
Copy link
Contributor

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.

@domoritz
Copy link
Member

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.

#274 (comment)

@domoritz
Copy link
Member

Closing for now since we have #355 with much better ts support.

@domoritz domoritz closed this Apr 24, 2024
@calvinfo
Copy link
Author

Thanks @domoritz! Excited to give it a shot when I pick up the project again.

@willium
Copy link
Member

willium commented Apr 28, 2024

I put these partial declarations together for my own needs while waiting for #355 to land

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants