Conversation
|
@ryanclark - this PR will require admin approval to merge due to its size. Consider breaking it up into a series smaller changes. |
|
Note - I had tried to add |
ravicious
left a comment
There was a problem hiding this comment.
I went through the tshd client. I'm yet to build the app, but I definitely want to look into how the final packaged app looks like structure-wise. I can also do a local signed build before we take it to CI.
There was a problem hiding this comment.
Orca Security Scan Summary
| Status | Check | Issues by priority | |
|---|---|---|---|
| Infrastructure as Code | View in Orca | ||
| Vulnerabilities | View in Orca | ||
| Secrets | View in Orca |
cc118a6 to
2a6b4a2
Compare
|
Grzegorz and I want to go through Connect's test plan again once we merge this into master and make a dev build off of v15 with these changes. But what about the changes in Web UI, how are we going to test them? |
|
If we merge it to master and backport to v15 only after a few days, it'll be inconvenient to anyone working on the Web UI code that interacts with types from protos. Once we get everything working in this PR, we should probably do tests on the v15 dev build and only then merge to master, followed by a quick backport to v15. |
There was a problem hiding this comment.
Could someone double check this change here?
There was a problem hiding this comment.
This change should be fine I think, @gzdunek AFAIK it was to accommodate for some weird Timestamp shenanigans in protos?
There was a problem hiding this comment.
I think so, I will make sure that the correct date is sent with the usage events.
There was a problem hiding this comment.
Except for the wrong environment, usage events are sent correctly.
There was a problem hiding this comment.
This is so much nicer than how I implemented it!
ravicious
left a comment
There was a problem hiding this comment.
I went through the whole PR and everything appears to be okay just from looking at the code alone. We'll run the Connect test plan on 15.0.0-dev.ravicious.10 just to double check.
ravicious
left a comment
There was a problem hiding this comment.
Okay, we ran the test plan against v15.0.0-dev.ravicious.10 and it looks everything works fine. What's next, do we wait for the protobuf PRs to land in master?
Yep |
Otherwise process.env in the main process is always replaced with an object containing just NODE_ENV. We need process.env to be properly populated since it's then used when spawning tsh daemon and other processes. Using define like this guarantees that only callsites using process.env.NODE_ENV directly will be affected.
…C UserPreferences object
a5410b4 to
e9df594
Compare
e9df594 to
93d66cb
Compare
This moves Connect's build & development tooling over to Vite.
In order to use Vite (which doesn't like CommonJS includes unless it's a 3rd party module), I had to swap over our JS protobuf generation to TypeScript - this is actually a nice advantage, because we can now use the protobuf types in the Teleport codebase. It also fixes a few type issues/FIXMEs in the codebase. I moved user preferences over to using the protobuf files as there was intertwined logic between Teleterm, Teleport & the gRPC representation, so I simplified it.
Sorry for the large PR. These changes were a result of changing one thing and then fixing the errors, changing another, fixing those, etc - it was hard to keep these concise and in separate, ordered commits.
Speed improvements
Start -
Vite - 5.89 seconds
Webpack 22.7 seconds
Build -
Vite - 14.28 seconds
Vite (bytecode) - 168.26 seconds
Webpack - 92.64 seconds
Caveats
The
oneOfrepresentation in@protobuf-ts/pluginonly works ifstrictNullChecksis enabled. I tried to enable this, but I couldn't get Connect to only be checked and not Teleport.To get around this, I added some helpers to ensure type safety. There's only 3 different oneOf values to check in the codebase, and I don't think it's too tedious to add new helpers for new values. If the protobuf representation changes, the types will break, so they will always be in sync.
Things to test
agentCleanupDaemon.jsrequireswinston, but it's not included innode_modules. Webpack used to bundle it intoagentCleanupDaemon.jsitself.$HOMEdoesn't seem to work, opening a new local shell tab whileDocumentClusteris active opens/instead of~.process.env.NODE_ENV)yarn dev-termand packaged app are considered to be the same app by Electron, preventing both from running at the same time.