Skip to content
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

Upgrade webapp dependencies #9916

Closed

Conversation

timroes
Copy link
Contributor

@timroes timroes commented Jan 31, 2022

What

Upgrade a bunch of used dependencies. It leaves a couple of major version updates of some dependencies unsolved, since they require more changes than I wanted to put into one PR.

How

See inline comments for more details where I actually changed code, and it wasn't simply a reformatting. I've also did a couple of minor updates where the code was anyway touched due to upgrade (also see inline comments).

I've tested that the pre commit hooks, building, running and running storybook are still working after this update.

@timroes timroes requested review from jrhizor and jamakase January 31, 2022 11:02
@github-actions github-actions bot added the area/platform issues related to the platform label Jan 31, 2022
@@ -33,5 +31,13 @@
"warn"
]
},
"parser": "@typescript-eslint/parser"
"parser": "@typescript-eslint/parser",
"overrides": [
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ℹ️ Disable requiring import syntax in scripts, since they are running on node directly so should use require for now.

@@ -1,4 +1,7 @@
module.exports = {
core: {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ℹ️ Required for making storybook run with webpack 5, which is used now in the updated react-scripts version.

@@ -56,27 +56,28 @@ const IGNORED_PACKAGES = [`airbyte-webapp@${version}`];
* Overwrite licenses for specific packages manually, e.g. because they can't be detected properly.
*/
const LICENSE_OVERWRITES = {
'glob-to-regexp@0.3.0': 'BSD-3-Clause',
'rework@1.0.1': 'MIT',
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ℹ️ Removed license overwrite for rework since no longer needed.

defaultMessage={sanitizedHtmlText}
/>
);
return <span dangerouslySetInnerHTML={{ __html: sanitizedHtmlText }} />;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ℹ️ The FormattedHTMLMessage component doesn't exist anymore in newer versions of react-intl. Instead the FormattedMessage supports now all the same HTML. That said, in this place the text/HTML we print is comping directly from the specification, and there is no purpose putting it through react-intl, since it would still be a single id (textWithHtmlTags), such we can't translate it that way. If we'd want those property descriptions to be internationalized, we'd anyway need to build a system for that. Thus changing this to a regular dangerouslySetInnerHTML for now, which is safe in this place, because we used sanitize-html beforehand.

Comment on lines +22 to +23
target: "_blank",
rel: "noopener noreferrer",
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ℹ️ Make sure all links are getting a proper rel tag to prevent the "opener attack" (see also https://mathiasbynens.github.io/rel-noopener/) in all browsers.

@@ -29,7 +29,7 @@ describe("applyProviders", function () {
innerProp: "1",
},
};
const providers: Provider<DeepPartial<Value>>[] = [
const providers: ProviderAsync<DeepPartial<Value>>[] = [
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ℹ️ Fixed some broken type, that apparently slipped previous TS versions.

@@ -120,6 +120,7 @@ const MainViewRoutes = () => {
path={`${r}/*`}
element={
<Navigate
// @ts-expect-error state is now unkown, needs proper typing
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ℹ️ location.state is now unknown. I've properly typed it in one file, where I could encapsulate custom type guards only within this file. This place here might need some utility type guard somewhere else, so left it untyped for now.

});
return (
login(values)
// @ts-expect-error state is now unkown, needs proper typing
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ℹ️ Same untyped location.state as above.

@@ -52,7 +71,7 @@ function usePreloadData(): {

const source = useResource(
SourceResource.detailShape(),
location.state?.sourceId
hasSourceId(location.state)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ℹ️ location.state is now unknown so added custom type guard in place to check for proper typing.

@@ -33,7 +44,9 @@ const DestinationForm: React.FC<IProps> = ({
const analyticsService = useAnalyticsService();

const [destinationDefinitionId, setDestinationDefinitionId] = useState(
location.state?.destinationDefinitionId || ""
hasDestinationDefinitionId(location.state)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ℹ️ Custom type guard for location.state, same as above.

@@ -34,14 +45,13 @@ const SourceForm: React.FC<IProps> = ({
const analyticsService = useAnalyticsService();

const [sourceDefinitionId, setSourceDefinitionId] = useState(
location.state?.sourceDefinitionId || ""
hasSourceDefinitionId(location.state)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ℹ️ Custom type guard for location.state, same as above.

@@ -304,6 +304,7 @@ describe("Service Form", () => {
const submit = container.querySelector("button[type='submit']");
await waitFor(() => userEvent.click(submit!));

// @ts-expect-error typed unknown, okay in test file
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ℹ️ result.connectionConfiguration is explicitly typed as unknown and was like that already before the upgrade. I have no idea how the previous typescript version did not catch this 🤔 Anyway, since it's a test file, simply ignoring this for now.

@@ -352,10 +354,6 @@ describe("Service Form", () => {
});

test("should fill right values oneOf field", async () => {
const credentials = screen.getByTestId(
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ℹ️ Removed unused code.

@@ -24,7 +24,8 @@
"noImplicitReturns": true,
"noImplicitThis": true,
"noImplicitAny": true,
"noFallthroughCasesInSwitch": true
"noFallthroughCasesInSwitch": true,
"useUnknownInCatchVariables": false
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ℹ️ By default TypeScript will now type the catch variable as unknown instead of any. This will though require a lot of more code changes whenever we catch exceptions. Thus disabling this for now, and continue typing the catch variable as any.

@jamakase
Copy link
Contributor

First of all, we shouldn't update prettier config while we have other work in progress as it will lead to a lot of merge conflicts.

This work should be done only after connection form refactoring pr is merged as it has bunch of changes.

What is more, we already have a lot of work done of dependencies upgrade in another pr which also includes updates in libs with breaking changes ( storybook and etc ).

@timroes
Copy link
Contributor Author

timroes commented Jan 31, 2022

First of all, we shouldn't update prettier config while we have other work in progress as it will lead to a lot of merge conflicts.

We will going forward always have a lot of work in progress in parallel. I don't think we can hold of "all large PRs merged" for tasks like prettier update in the future. It's more important, whether it will collide timing wise on merging in the future. Since it seemed there is no other frontend PR currently close to being merged (today or tomorrow), I'd prefer doing it now while running into a situation where we also have other work nearly ready to be merged. Since all prettier changes are auto fixable by lint, we should just run a npm run lint -- --fix after this is merged on any open PR.

What is more, we already have a lot of work done of dependencies upgrade in another pr which also includes updates in libs with breaking changes ( storybook and etc ).

Could you add a link to this PR? I couldn't find any area/frontend PR that did some major upgrades to dependencies?

@timroes
Copy link
Contributor Author

timroes commented Jan 31, 2022

This work should be done only after connection form refactoring pr is merged as it has bunch of changes.

What is the timeframe, on when this is planned to be merged?

@jamakase
Copy link
Contributor

Yes, but merge conflicts can't be addressed automatically with prettier. It means if prettier is changed, all other prs should be updated then. And they will have bunch of merge conflicts as prettier will be changed in master.

As prettier is just a tool and it is not a hard requirement in development process - updating it shouldn't lead to inconveniences for other team members. If it leads - it means that its update should be postponed for better timing.

What is the reason behind updating default prettier styling without any prior notice for other team members? I do not see why it couldn't wait a bit.

If you could take care of merging these prettier changes in all other branches and solving merge conflicts - then I have nothing against updating it now.

As for fixes - there is a branch in named jamakase/fix-webapp-dependencies

@timroes timroes temporarily deployed to more-secrets January 31, 2022 12:54 Inactive
@timroes timroes marked this pull request as draft January 31, 2022 12:54
@timroes timroes removed the request for review from jrhizor January 31, 2022 12:55
@timroes
Copy link
Contributor Author

timroes commented Jan 31, 2022

Removed the prettier upgrade from this PR, also postponing for discussion to our next weekly.

@timroes
Copy link
Contributor Author

timroes commented Feb 21, 2022

Superseeded by #10507

@timroes timroes closed this Feb 21, 2022
@timroes timroes temporarily deployed to more-secrets February 21, 2022 16:42 Inactive
@timroes timroes temporarily deployed to more-secrets February 21, 2022 16:42 Inactive
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/platform issues related to the platform
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants