Move node dependencies out of commons and engine #2500
Conversation
| @@ -46,7 +46,7 @@ export class NormalizedIDE extends PassthroughIDEBase { | |||
| hatStability: this.configuration.getOwnConfiguration( | |||
| "experimental.hatStability", | |||
| ), | |||
| snippetsDir: getFixturePath("cursorless-snippets"), | |||
| snippetsDir: this.cursorlessSnippetsDir, | |||
There was a problem hiding this comment.
This implementation I'm not quite happy with. The problem is that normalized ide is used in the extension bundle and uses a environment fixture path. I will happily take any suggestions here.
There was a problem hiding this comment.
I mean NormalizedIDE is really test / dev code, so probalby shouldn't be in engine / common. But I'm ok with this for now
AndreasArvidsson
changed the title
AndreasArvidsson
changed the title
There was a problem hiding this comment.
Made a couple tweaks. Seemed better to check for relative in the engine for consistency. Merge if you're happy with my changes https://github.com/cursorless-dev/cursorless/pull/2500/files/cd71783e6aa8f73e026a7e46e6b2d78e8c867cc5..73a2f35febe5af8362c2f982070d1f28f805acd8
|
Looks good. Thanks for reviewing this many changes so quickly :) |
This is all about getting node out of commons. A lot of our file system interaction had to do with running tests and reading/writing test fixtures so I created a separate node test package.
To avoid circular dependencies I had to move a bunch of types from the engine to commons. This make it so we now have changes in imports in a bunch of different files. Most of the changes are quite mechanical or boilerplate. The only actual new code is the two storage providers to
ScopeTestRecorderandTestCaseRecorder. The latter one is quite lacking in implementation. This is just about unblocking cursorless everywhere. A better abstraction is something we can workshop together.And before you ask: no I can't split this into smaller pr. It feels like a small miracle that I could solve all of the circular dependency problems I had already :)
I wonder if we in a follow up want to move everything test related to the test package? Generally I prefer to have test as close to the source code as possible but in this case it's getting problematic to keeping track of all the dependencies. If we had a test package we could make sure that a lot of the dependencies only existed in that package and we could add lint rules preventing them in the other packages.
Checklist