VS Code links to docs pages that seem to no longer resolve

[mit-mit]

As part of the getting stated install flow, our VS Code plugins link to instructions in our docs for setting path using Urls like https://docs.flutter.dev/get-started/install/windows#update-your-path:
https://github.com/Dart-Code/Dart-Code/blob/master/src/shared/constants.ts#L96

Did these Urls change recently? It looks like they no longer resolve. If so, we should put redirects in place.

[atsansone]

Redirects:

• https://docs.flutter.dev/get-started/install/windows/desktop?tab=download#update-your-windows-path-variable
• https://docs.flutter.dev/get-started/install/macos/desktop?tab=download#add-flutter-to-your-path

Linux will change after #10302 merges.

[mit-mit]

@atsansone was this resolved?

[atsansone]

@mit-mit : I may need to create a hidden page that covers this. I checked with @kenzieschmoll about changing this in future DevTool versions.

[mit-mit]

We still need older releases to work though. Can you just add redirects for the old Urls?

[atsansone]

Unfortunately, no. The Firebase JSON redirects can't point from URL fragment to URL fragment. (See angular/angular#45861.)

So, this redirect can't be made:

{
"source": "/get-started/install/:platform#update-your-path",
"destination": "/get-started/install/:platform/desktop?tab=download#add-flutter-to-your-path",
"type": 301
},

This is why I'm thinking about a hidden page. That way I can link to a whole page, rather than a URL fragment.

[sfshaza2]

OK, I've been familiarizing myself with the current way this is set up. Wow, what a labyrinthian implementation. I wasn't aware that you can't redirect (in Firebase) from one anchor on one page to another anchor on another page. Is this, perhaps, because the link also contains a platform variable?

I'm tempted to suggest that the VSCode plugin be updated to do a Google search for "setting up path flutter platform", but changing VSCode isn't a desirable solution here. Let me think on it more. (I've also asked @parlough if he has any ideas.)

[sfshaza2]

Oh, about the hidden page idea. Would it require documenting how to set the path for ALL platforms and ALL shells on said page? If so, that seems pretty icky

[sfshaza2]

Actually, I think a better solution is to create a "go" link, such as "docs.flutter.dev/go/set-flutter-path" and that link can be changed without any issues, I think. Once again, this requires changing the VSCode plugin, as well as the site, but it feels much cleaner than the hidden page idea.

(In general, we should use this solution for all links to the docs from our tools. Set up a go link that can easily be updated.)

[kenzieschmoll]

CC @DanTup

[parlough]

We still need older releases to work though. Can you just add redirects for the old Urls?

Unfortunately, not in the traditional way with the setup chosen for the new pages since fragments aren't sent to the server. To support the old links, I added a JS based redirector in #10115. I accounted for some fragments from the framework, but not all of them. I can update those scripts and add one for Linux to account for more fragments.

Edit: Opened #10357

Actually, I think a better solution is to create a "go" link, such as "docs.flutter.dev/go/set-flutter-path" and that link can be changed without any issues, I think.

For the future, yes please. This is what we do on the Dart site for destinations that pub wants to link to. Since we reserve /go/... for design docs on flutter.dev, we should consider a different prefix to standardize on. Any preferences or ideas?

[DanTup]

I think a better solution is to create a "go" link, such as "docs.flutter.dev/go/set-flutter-path" and that link can be changed without any issues

I agree, creating stable URLs not tied to the specific structure of the site would be better. I can update the VS Code extension and push out a patch if new URLs are available.

People tend to update the VS Code extension fairly quick, so old plugins hopefully aren't a bit problem for a long time - however I wonder if we could just put the javascript inside the patch to read the fragment and redirect client-side if a "legacy fragment" is there? I didn't read the whole thread before responding, and that's exactly what @parlough has done 😄

[DanTup]

Should I update the links in the VS Code extension too?

If there may be shorter go/-style links in future maybe we should wait for them, but otherwise it might be worth updating to the current redirect targets?

[parlough]

@DanTup I'd hold off on updating. I'll start some discussion on what path we're going for the /go/ style links and create some initial ones. I'll post updates to #10363 as I have them.

If you have a chance, could you comment on that issue with the various destinations/topics that VS Code currently needs or might need links to? Thanks :D