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

Multiple modules #1379

Merged
merged 14 commits into from
Mar 6, 2024
Merged

Multiple modules #1379

merged 14 commits into from
Mar 6, 2024

Conversation

johnfairh
Copy link
Collaborator

@johnfairh johnfairh commented Feb 8, 2024

Thanks to the efforts from last year (#1369) there's a prototype and a lot of thoughts about this, so let's see how much further it can go without too much risk to existing projects.

  • Full config model & abstraction
  • Spec testcase
  • Disentangle concept of "the module name" from various places
  • Fix page breadcrumbs
  • File layout to avoid name collisions
  • Grouping policies
  • UI notes for cross-module extensions
  • Name resolution for custom categories
  • Name resolution for autolinks
  • Docs

Testcase / demo in spec/integration_specs/jazzy_multi_modules, 3x Swift & 1 ObjC module.

Ready to go now, will let it sit a bit first.

Copy link

github-actions bot commented Feb 8, 2024

1 Warning
⚠️ Big PR

Generated by 🚫 Danger

@johnfairh
Copy link
Collaborator Author

Some pathological extension-merging...
Screenshot 2024-02-16 at 11 06 17

@johnfairh
Copy link
Collaborator Author

johnfairh commented Feb 21, 2024

Autolinking was quite an effort; at least I understand what it was doing now. The various test specs have changes which are all improvements/bug fixes --- far too much effort to reimplement the bugs:

  • Moya -- was somehow linking from the LHS of a typealias, doesn't do that any more
  • RealmSwift -- autolinking to Object and stuff nested in typealias'd extensions now works
  • Siesta -- LHS typealias again, plus it was using a module-qualified name in one place that now works
  • JazzyMultiModules -- new examples/tests for x-module name ambiguities etc

I am confident the rework is good, the specs exercise all the paths in so many weird ways.

argjiramala-tomtom and others added 14 commits February 28, 2024 17:21
Document multiple modules which are Xcode project on their own or part of a workspace

Update the build configuration

* rename the command line attribute to modules
* use config file for module to build Xcode project

build the project with configuration from config file

chore: remove tomtomsdk from jazzy

feat: Add extensions to proper module.

renaming of config variables for multiple modules

Co-Authored-By: Pedro Alcobia <102952330+PedroAlcobia-TomTom@users.noreply.github.com>
Nested config file objects with selected attributes for modules.

Add 'doc module name' sourcedeclaration attribute saying where the
declaration was found, vs. 'module name' saying where the decl's
nominal is from.

Quick and dirty updates to prototype code to make it pass rubocop.
Provide a separate option to set the docset title instead of using
the module name.  Refactor to pull all the docset stuff into the
docset code.
Add a new flag to set this thing manually.
Make the page breadcrumbs actually reflect the navigation hierarchy.

Include a type's module name when it's from an external module or
not clear from the breadcrumb list.

Affects all specs.
Each module into its own directory.
  Each module that has extensions in its own subdir
  No need to separate classes/enums etc even in ObjC
Add —merge-modules all/extensions/none and implement merging and unmerging with
custom categories and guides.
User docs for this later when happy.
Extend test case to demonstrate.
Include a note where necessary to show what the user has to import
to get access to the declaration.

Three mechanisms for showing module source, increasingly fine
granularity:
1. The outer group name in the left nav/first breadcrumb.
  
This is set to the module name for merge=none/extns.
2. The top-level decl name in the breadcrumbs.
  
This includes the module name only when mech#1 fails.
3. A decl note in the parent page.
For when mech#1,2 fail.
   This commit.
   For example a decl added by an extension or a top-level decl
   with no children (eg. free function, marker protocol).

The idea is that jazzy use the widest-scope mechanism possible,
falling back to the more visually noisy ones only when necessary.
This is to resolve the issue of merging extensions that provide
protocol compliance -- in this case there may be no members to annotate
and show the source module.

A bit messy and not entirely complete because of the way the code is
structured -- really we should rework 'declaration' to be a list of
stuff for the templating layer but it is already tangled up with html
because of Rouge.

Good enough though, covers everything, and in reality these are unusual
cases.
Add module-aware doc index tree.
Reimplement autolinking to use the tree.
This makes linking module-aware and deals with the ambiguities.
Rebase, docs, last-minute objc fixes

ObjC namespaces are confused by the 'tag' and typedef rules from
ye olde C so have to revert to the fuller directory structure.  To
make things simpler and less risky, just keep that for the Swift
version too.
@johnfairh johnfairh marked this pull request as ready for review February 28, 2024 18:59
@johnfairh johnfairh merged commit 7e8a61a into master Mar 6, 2024
5 checks passed
@johnfairh johnfairh deleted the jf-mm branch March 6, 2024 10:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants