Add root alias, use for style/common.css import #4907
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Vadman97
approved these changes
Apr 10, 2023
Vadman97
pushed a commit
that referenced
this pull request
Apr 10, 2023
## Summary <!-- Ideally, there is an attached GitHub issue that will describe the "why". If relevant, use this section to call out any additional information you'd like to _highlight_ to the reviewer. --> _This is part of a [series](#4813) [of](#4848) [PRs](#4849) [being](#4851) [spun](#4852) [off](#4907) from [my WIP branch](lewisl9029#2) to get the Highlight web app ready for [Reflame](https://reflame.app/). Hopefully this makes things a bit easier to review, test, and merge. 🙂_ We had both a `CommentTextBody.module.css` and a `CommontTextBody.module.scss` previously. The scss module seems to be for regular component styling, while the css module seemed to be mostly meant to contain classes for the `@highlight-run/react-mentions` classNames prop integration. I ended up renaming `CommentTextBody.module.css` to `mentions.module.scss` to better reflect its purpose and distinguish it from the main styling module, and so there wouldn't be any name conflicts when generating corresponding .js modules for the Reflame integration. There also seemed to be 2 classes in the css module that didn't have anything to do with mentions, so I moved those out as well. ## How did you test this change? <!-- Frontend - Leave a screencast or a screenshot to visually describe the changes. --> Tested this out in the Reflame preview:  ## Are there any deployment considerations? <!-- Backend - Do we need to consider migrations or backfilling data? --> We do probably want to verify in Render as well to make sure Vite has the same exports output for CSS and SCSS modules.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This is part of a series of PRs being spun off from my WIP branch to get the Highlight web app ready for Reflame. Hopefully this makes things a bit easier to review, test, and merge. 🙂
Previously we had a bunch of places where we imported
/src/style/common.cssusing the identifierstyle/common.css.style/*was not setup as an alias in tsconfig.json, but this seem to have worked anyways (I think it might be a quirk of the https://github.com/aleclarson/vite-tsconfig-paths plugin).I don't think it's a good idea to rely on this behavior over the long term since there's nothing distinguishing it from npm package imports.
We could have worked around this by adding a
@stylesidentifier like we have for most other top level folders, but in this PR I proposed what I believe is a more flexible option of simply exposing the src directory as a@/*alias.This has several benefits over manually setting up aliases for top level folders separately:
@/*matches the filesystem directory structure exactly, so there's never any ambiguity to where an imported file actually lives on disk (in our current setup, we have 2 aliases that don't map 1:1 to top level folders@icons/*and@graph/*)That said, this PR just introduces the new alias and uses it for
@/style/common.css, and doesn't change any other existing imports, so none of these benefits are actually realized here. Though if the team is interested in moving forward with this, I'd be happy to open up a follow up PR to update imports throughout the rest of the codebase as well, and try running a few benchmarks to see if it actually moves the needle on performance.Alternatively, let me know if y'all prefer to keep the current approach using manual top level path remappings instead. I'd be happy to switch over to a
@styles/*import here as well.How did you test this change?
I ran the app using
yarn turbo run dev --filter frontend....Are there any deployment considerations?
None that I'm aware of.