VSCode seems lazy discovering generated code

[danielkcz]

Sorry for the issue, not sure where else to put it (can you enable discussions?).

I don't know what's wrong, but when I do some change to a machine, save it, xstate-codegen runs and yet in VSCode I still see a type error. Even when I keep the generated file open in the tab it doesn't refresh. Only after I switch to it and back, the VSCode sees the change, and checks are working fine.

I assume it's some settings, but I just don't see anything suspicious here. Did anyone encounter something similar?

{
    "diffEditor.renderSideBySide": false,
    "editor.codeActionsOnSave": {
        "source.fixAll.eslint": true
    },
    "editor.defaultFormatter": "esbenp.prettier-vscode",
    "editor.fontFamily": "'Fira Code Light'",
    "editor.fontLigatures": true,
    "editor.formatOnSave": true,
    "editor.minimap.enabled": true,
    "editor.minimap.maxColumn": 80,
    "editor.minimap.renderCharacters": false,
    "editor.renderControlCharacters": false,
    "editor.renderWhitespace": "boundary",
    "editor.suggest.maxVisibleSuggestions": 15,
    "editor.suggestSelection": "recentlyUsedByPrefix",
    "editor.tabCompletion": "onlySnippets",
    "eslint.codeActionsOnSave.mode": "problems",
    "eslint.packageManager": "yarn",
    "explorer.openEditors.visible": 0,
    "extensions.ignoreRecommendations": true,
    "git.autorefresh": true,
    "git.countBadge": "tracked",
    "git.openDiffOnClick": false,
    "git.promptToSaveFilesBeforeCommit": "staged",
    "git.untrackedChanges": "separate",
    "html.suggest.html5": false,
    "javascript.validate.enable": false,
    "less.validate": false,
    "npm.packageManager": "yarn",
    "oneDarkPro.editorTheme": "vscode",
    "oneDarkPro.italic": false,
    "scss.validate": false,
    "search.smartCase": true,
    "terminal.integrated.rendererType": "canvas",
    "typescript.disableAutomaticTypeAcquisition": false,
    "typescript.format.enable": false,
    "typescript.locale": "en",
    "typescript.preferences.importModuleSpecifierEnding": "minimal",
    "typescript.preferences.useAliasesForRenames": false,
    "typescript.surveys.enabled": false,
    "typescript.tsc.autoDetect": "off",
    "typescript.tsdk": "node_modules/typescript/lib",
    "typescript.tsserver.log": "terse",
    "typescript.tsserver.trace": "messages",
    "typescript.updateImportsOnFileMove.enabled": "always",
    "typescript.validate.enable": true,
    "window.zoomLevel": 0,
    "workbench.colorTheme": "One Dark Pro",
    "workbench.editor.closeEmptyGroups": false,
    "workbench.iconTheme": "material-icon-theme",
    "workbench.sideBar.location": "right",
    "workbench.startupEditor": "newUntitledFile"
}

[mattpocock]

@FredyC This is fine as an issue - no worries. Discussions is beta-only, sadly.

I also ran into this, but pushed a version that fixed it for me. 0.1.3 was the version in which I pushed the fix.

Which version are you on?

[danielkcz]

Ah sorry, a version is 0.2.0, so I guess it's something else in my case?

To be honest, I noticed this behavior of VSCode with graphql-code-generator as well. Any changes are not refreshed until I open the generated file.

I was only able to google some old VSCode issues microsoft/vscode#31600 microsoft/vscode#21252, but nothing useful there.

[mattpocock]

The long-term plan is to fold xstate-codegen in with a VSCode extension. Once we're integrated with VSCode properly, we'll be able to do things like alert Typescript's language server that a change has occurred in the file.

Until then, let's see if we can at least improve it for you. What OS are you on? This may make a difference. I am on MacOS and not seeing this slowdown any more.

[danielkcz]

Well, Windows 10, but I would expect it should be fine given it's both Microsoft products 😕

However, I am also using Windows Subsystem for Linux and I am connected to it through remote dev. It's effectively a true Ubuntu running inside Windows with the filesystem and everything. I guess that's a lot of unknowns considering :)

[mattpocock]

Interesting... It could be a remote VM thing. It's not working on the codesandbox demo I put together:

https://codesandbox.io/s/intelligent-bhaskara-7etw2?file=/src/demo.machine.ts

[mattpocock]

I'd be interested to keep this issue here and see if others are experiencing the same issue. I thought I'd found a fix (0.1.3) but we should hear if others are seeing the same thing.

[danielkcz]

WSL2 is not VM based, it's running full Linux kernel in the OS.

[danielkcz]

Ok, I tried running your example locally within Windows and it's working correctly there. So you are right, it's the remote dev most likely. But I am not giving up WSL for this, because ext4 beats ntfs :)

I guess I will try opening the issue with them tomorrow.

[danielkcz]

Ah, I fiddled with it more and got interesting discovery.

I've moved compiled folder from node_modules into src and referenced to it relatively in my source code. Then modified the generated index.d.ts in the external editor and VSCode has refreshed it correctly even within WSL.

Not sure why node_modules would be a problem in WSL, but not on Windows. But it's a viable workaround if you would allow specifying a path where to write generated files.

I see now that outDir is already available but for some reason, it did not help. I will investigate more tomorrow.

Looks like I was just impatient. It works with this option, it just takes a 2-3 second in my project, but I have general performance issues with TS, so that's not about codegen.

[mattpocock]

OK great, I'm glad that outDir works for this use case. Can we close the issue?

[danielkcz]

I think it would be still interesting to investigate why node_modules is a problem, but otherwise feel free.

[danielkcz]

While investigating #47 and after applying "workaround" of moving code generation to root it seems it also solved this issue of lazy refresh. Apparently, VSCode fails to see changes in the subfolder node_modules. Now it's ok to close this :)