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

Add Link view, update JavaScriptKit to 0.8.0 #276

Merged
merged 8 commits into from Nov 5, 2020
Merged

Conversation

carson-katri
Copy link
Member

@carson-katri carson-katri commented Sep 17, 2020

The Link View is added in this PR. I also upgraded JavaScriptKit to 0.8.0.

NOTE: Publish integration is being moved to TokamakUI/TokamakPublish

This adds the ability to use TokamakStaticHTML in place of Plot.

A tokamakFoundation theme is provided, and custom ones can be created with the TokamakHTMLFactory protocol.

That requires implementing the following functions:

func makeIndexView(for index: Index, context: PublishingContext<Self.Site>) throws -> IndexView
func makeSectionView(
    for section: Publish.Section<Self.Site>,
    context: PublishingContext<Self.Site>
  ) throws -> SectionView
func makeItemView(for item: Item<Self.Site>, context: PublishingContext<Self.Site>) throws
    -> ItemView
func makePageView(for page: Page, context: PublishingContext<Self.Site>) throws -> PageView
func makeTagListView(for page: TagListPage, context: PublishingContext<Self.Site>) throws
    -> TagListView
func makeTagDetailsView(for page: TagDetailsPage, context: PublishingContext<Self.Site>) throws
    -> TagDetailsView

These will be rendered to HTML, and embedded in Plot.HTML elements.

You can then declare your theme with an extension on the Theme struct:

extension Theme {
  public static var yourThemeName: Self {
    Theme(htmlFactory: FoundationTokamakFactory())
  }
}

If you haven't used Publish before, you can install the CLI with:

git clone https://github.com/JohnSundell/Publish.git
cd Publish
make

Then run publish new and add TokamakStaticHTML as a dependency.

@carson-katri carson-katri added the enhancement New feature or request label Sep 17, 2020
@MaxDesiatov
Copy link
Collaborator

Fabulous! I was thinking of proposing something like this literally a few days ago, so glad this will be resolved soon 👏

Package.swift Outdated
@@ -4,6 +4,16 @@

import PackageDescription

#if os(WASI)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Does this actually have the desired effect? Package.swift is evaluated on the host platform, not on the target platform, so #if os(WASI) condition will never be evaluated until we have a self-hosted toolchain running in the browser (we probably won't for long time). These kind of exclusion of dependencies should be implemented with condition: .when(platforms: [.wasi]), as done for the TokamakShim target below.

This check also seems to be the reason for the Linux build failing.

Copy link
Member Author

Choose a reason for hiding this comment

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

Oops! 😂

Although conditions don't seem to work, as we can't depend on a version # of JavaScriptKit since it has unsafe build flags, unless I'm doing something wrong? Should I just change the JavaScriptKit dependency to a commit?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Are you using a recent 5.3 SwiftWasm snapshot as recorded in the .swift-version file in main? These snapshots allow adding JSKit with a version as a dependency, even with unsafe flags.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I see what you mean, Swift toolchains for other platforms don't have the unsafe flags workaround. I hope that if you don't attempt to build products that depend on JavaScriptKit, it won't complain about unsafe flags? As in swift build --product TokamakStaticHTML, or when you build something that depends on Tokamak, but doesn't depend on TokamakDOM?

Copy link
Member Author

Choose a reason for hiding this comment

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

In my publish test project it seems to resolve the dependencies for all the products, not just TokamakStaticHTML...

Copy link
Collaborator

Choose a reason for hiding this comment

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

Even if we add new LinkerSetting values, we still need upstream to support them. Now is the best time to submit a PR with these settings upstream before the new major version is branched off, but it means that we still can't create a package manifest that declares these new safe linker settings consumable with upstream Swift 5.3. Or am I missing something?

Copy link
Contributor

Choose a reason for hiding this comment

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

The only way we can take to avoid this issue is to separate this repository into a package that depends on JavaScriptKit and a package that doesn't depends on JavaScriptKit until next major version will be released.

Copy link
Collaborator

Choose a reason for hiding this comment

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

As far as I know, Swift 5.3 still downloads the whole tree of dependencies without checking whether they're used or not. This was fixed in apple/swift-package-manager#2749, but it was merged after Swift 5.3 was branched off.

Copy link
Contributor

Choose a reason for hiding this comment

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

I can't figure out another idea 🤷 Tokamak users must use wasm toolchain now.

Copy link
Collaborator

Choose a reason for hiding this comment

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

A horrible hack would be to patch SwiftPM to check whether it's linking JavaScriptKit and to inject the required linker flags. This probably isn't worse than what we do now, as SwiftPM in 5.3 SwiftWasm snapshots already checks for a package name and allows unsafe flags if it's JavaScriptKit. But submitting a PR upstream to allow more linker flags is a priority then. I don't want to miss the next version cut-off again. 🙏

@carson-katri
Copy link
Member Author

@MaxDesiatov this builds and runs with the latest carton. Does the swiftwasm-action need to be updated to a newer snapshot?

@MaxDesiatov
Copy link
Collaborator

Yes, I'll do that in the next few days, there are a few more changes I want to land in SwiftPM to allow OpenCombine tests to run. If it's urgent for you, please feel free to submit a PR to the swiftwasm-action repo, you probably also have enough permissions to upload a new image yourself after that PR is merged. Or maybe we should automate that if it's not done yet.

@carson-katri
Copy link
Member Author

No rush 🙃

@MaxDesiatov
Copy link
Collaborator

Sorry for the delay, I'm aware that we have too many stalled PRs and I want to get it all moving again. It's just toolchain and carton changes consumed too much of my development capacity...

I also hope I'm not completely blocking everything. If there's anything you can't do without me, but you'd like to proceed on your own anyway, please feel free to ping me. I want our projects to be as distributed as possible without bottlenecks in communication and other dev processes.

@MaxDesiatov
Copy link
Collaborator

Another thing I had in mind for this PR: does this Publish integration require access to anything private or internal in Tokamak? Would it work better as a separate package, and a Publish plugin?

@carson-katri
Copy link
Member Author

It can definitely work as a separate package. As for making it a Publish plugin, those aren't really meant for building the theme from my understanding, so I don't think it'd work as one.

@MaxDesiatov
Copy link
Collaborator

Cool, feel free to create a repo for the package in this org if you'd like. I think a separate repo would be more suitable. It would allow specifying a dependency on a specific version range of Publish.

It would also mean we can add support for other static generators in the future separately. Otherwise we'd need to maintain all other integrations within this repo, or Publish would be the only privileged one.

@carson-katri
Copy link
Member Author

Would TokamakPublish work as the name?

@MaxDesiatov
Copy link
Collaborator

LGTM 👍

@carson-katri
Copy link
Member Author

Keeping this PR open because it adds the Link view and JSKit still needs to be upgraded to 0.8.0 so it can build.

@carson-katri carson-katri changed the title JohnSundell/Publish integration Add Link view (was JohnSundell/Publish integration) Oct 31, 2020
@MaxDesiatov
Copy link
Collaborator

I've uploaded new swiftwasm-action and carton Docker images with the latest toolchain just now, in case those are still needed.

@carson-katri
Copy link
Member Author

Awesome, CI is now passing 👍

@carson-katri carson-katri requested a review from a team November 2, 2020 19:35
@MaxDesiatov MaxDesiatov changed the title Add Link view (was JohnSundell/Publish integration) Add Link view, update JavaScriptKit to 0.8.0 Nov 2, 2020
Copy link
Collaborator

@MaxDesiatov MaxDesiatov left a comment

Choose a reason for hiding this comment

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

LGTM 👍

@MaxDesiatov
Copy link
Collaborator

@carson-katri is this ready to merge?

@carson-katri carson-katri merged commit 348408e into main Nov 5, 2020
@carson-katri carson-katri deleted the publish-support branch November 5, 2020 21:37
MaxDesiatov added a commit that referenced this pull request Nov 7, 2020
Requires #276 to be merged, as earlier versions of JavaScriptKit can't be depended on in macOS builds due to unsafe flags.

* Add Link View

* Add Publish support

* Remove #if checks

* Upgrade swift snapshot

* Try swiftwasm-action@main

* Remove Publish support from this repo

* Remove TokamakPublish target

* Allow tests to be run on macOS

* Update `ci.yml` to build and run the test product

* Trigger CI on all PRs without branch restrictions

* Rename linux_build to swiftwasm_build in ci.yml

Co-authored-by: Carson Katri <carson.katri@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Development

Successfully merging this pull request may close these issues.

None yet

3 participants