-
Notifications
You must be signed in to change notification settings - Fork 35
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
🐈🐈🐈 #657
The head ref may contain hidden characters: "\u{1F408}.json"
Conversation
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 still think having .civet
as a format would be useful, partly because we don't (yet) support YAML, and Civet is a good approximation thereof. I agree it can only use the default config, but I think that's fine when all you're writing is
export default
coffeeCompat: true
but I'd still rather write that than
{"coffeeCompat": true}
I'm hopeful that civetconfig.civet
is a sufficiently specific name that it won't conflict with user's filenames... Probably 🐈.civet
too. But we obviously do need to remove config.civet
.
@@ -3,9 +3,7 @@ | |||
import { readFile } from 'fs/promises'; | |||
import { pathToFileURL, fileURLToPath } from 'url'; | |||
|
|||
import CoffeeScript, { compile } from "coffeescript"; | |||
// Handle cjs .coffee files | |||
CoffeeScript.register() |
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 it's nice to keep this registration in case others want to use this as a CoffeeScript ESM handler. So I lean toward keeping it, but it's also OK to remove it and leave this for a CoffeeScript issue (actually jashkenas/coffeescript#5447).
source/config.mts
Outdated
@@ -0,0 +1,72 @@ | |||
import path from "path"; |
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.
Any particular reason for the move from CoffeeScript? I preferred that version, and it's more consistent with the rest of the code (e.g. Ah, I see, but we want to move toward full typechecking, so this makes sense.main.coffee
).
source/config.mts
Outdated
"🐈.civet", | ||
"civetconfig.json", | ||
"civetconfig.civet", | ||
].includes(name)) { |
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.
name in ['config.civet', 'civet.json', 'civetconfig.civet', 'civetconfig.json']
has a more efficient compilation in CoffeeScript than this. But I guess we could do even better with a Set
(hoisted to global scope).
Wait, how can |
I added a devDependecy for a previously published civet version so we can us that in development as long as we reference it from |
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 right, I see it now. Amazing — we can now live the Civet future!!
Is it possible to switch lib.ts
over too? Or is there an issue when mixing with Hera? That is where we could probably benefit most from Civet.
source/config.civet
Outdated
@@ -0,0 +1,72 @@ | |||
import path from "path"; |
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 a high priority, but now that we're using Civet instead of TS, we could make this code closer to the CoffeeScript version you're replacing here (but with type annotations). Could be saved for the future though.
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.
So exciting!!! Civetception!
"./build/hera-esm.mjs", | ||
"./dist/esm.mjs" | ||
"./node_modules/@danielx/civet/dist/esm.mjs" |
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.
Will this use the correct version of Civet? We need tests to run in the repo version, not in the released version.
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.
This is the version that will parse the source and test files. Once parsed the tests are run against main.civet
, lib.civet
, parser.hera
, etc.
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, got it. (If only we could add a comment to a JSON file. 😉)
That seems fine, because we don't generally use fancy features in the test infrastructure, only inside the triple quotes. Actually, in some ways, it will be an improvement; I've run into issues where I break the Civet compiler (and ran yarn build
) and then yarn test
crashes, with unhelpful error messages. This should avoid that sort of issue.
@@ -225,7 +225,7 @@ export base64Encode = (src) -> | |||
|
|||
# Accelerate VLQ decoding with a lookup table | |||
vlqTable = new Uint8Array(128) | |||
vlqChars = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/' | |||
vlqChars = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/'; | |||
do -> |
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 don't understand how this Funny, there was already a do ->
works without coffeeCompat
mode enabled. Are we sure it's actually running?coffeeCompat
flag in a .coffee
file. Is the following comment (at the top of the file) of interest?
# NOTE: Hera has an updated version of this file converted from CoffeeScript to Civet.
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 directive was from some earlier testing.
We should probably export these utils from Hera as the definitive source eventually.
@@ -43,15 +42,14 @@ | |||
"@cspotcode/source-map-support": "^0.8.1" | |||
}, | |||
"devDependencies": { | |||
"@danielx/civet": "^0.6.26", |
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'd feel safer if this were a pinned dep (no ^
). Given how we tend to change things and just bump the patch number. 😅
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 believe the lockfile should take care of it but being explicit here would also be fine.
By the way, it's also really great what a stress test this was, for both JavaScript and CoffeeScript compatibility. Thanks for writing down all the bugs you encountered. Time for another bug squashing session! 😄 |
I'm still sad about the build getting slower with the conversion from We can try a few things in the future:
|
All good ideas. And I'd rather pay the price of slowness and be able to dogfood. Civet should speed our development too. One thing we might try is profiling the compilation stage. I have no idea, for example, whether the dominant cost is running Hera rules/caching, or the |
I scope creeped this to now allow for
.civet
in our Civet build.Key ideas:
.civet
as our source files when building and testingAlso converted
lib.ts
->lib.civet
it uncovered several bugs but only needed minor changes. It is however a little slower (~5s) to parse and that is sad. Hopefully we can speed up the parser at it will be no worse than TS.Fixes #641 Config update:
config.civet
from name of config files to check.config
dir keep looking rather than returnnull
import