Stop vendoring imports so precompile times remain sensible?

[oxinabox]

On CI i have seen ExplictImports taking over 2 minutes to precompile. Which is completely unreasonable)
Locally, @KristofferC saw it take 10s (which still rather high).

A likely candidate is the vendoring of dependencies.
In particular JuliaSyntax, which is large.

ExplicitImports.jl/src/ExplicitImports.jl

Lines 4 to 10 in dbed49f

	# We vendor some dependencies to avoid compatibility problems. We tell ExplicitImports to ignore
	# these as we don't want it to recurse into vendored dependencies.
	# We also add `Vendored` to `ignore_submodules` elsewhere.
	module Vendored
	include(joinpath("vendored", "JuliaSyntax", "src", "JuliaSyntax.jl"))
	include(joinpath("vendored", "AbstractTrees", "src", "AbstractTrees.jl"))
	end

Given JuliaSyntax is a stdlib now and should be widely compatible.
Can it be changed to just use the stdlib version if the VERSION is high enough?

[ericphanson]

It’s not a stdlib but Base has a vendored copy too, so we might be able to use that one, except there’s pretty big breaking changes in different versions (v0.4 vs v1 vs v2), and I’m not sure which Julia’s use which.

[oxinabox]

One way would be to go fine the version via pulling out out with dirname(Base.module_loc(Base.JuliaSyntax....
and then parsing the Project.toml.
That's really annoying tho.

A simpler option might be just to check for presence of particular functions?
So can tell that I am using v1 because

julia> hasproperty(Base.JuliaSyntax, :haschildren)  # defined in 0.4
false

julia> hasproperty(Base.JuliaSyntax, :numchildren)  # defined in 1.0
true

Which i found by looking at
JuliaLang/JuliaSyntax.jl@JuliaLang:09576ca...JuliaLang:2e965a1

[ericphanson]

I think Julia v1.10 and 1.11 use v0.4, Julia v1.12 uses v1, and Julia v1.13 uses v2 (looking at https://github.com/JuliaLang/julia/blob/master/deps/JuliaSyntax.version). So we would need to simultaneously support 3 breaking versions of JuliaSyntax in this package to use the one from Base.

[oxinabox]

Or chose one version that is good and vender that one
then when that is not the one that is being used by Base (or one that is not compatible with it)
fall back to the vendered version?

It's not particularly uncommon to support multiple breaking versions of a dependency though.
But depends how breaking of course.

[ericphanson]

yeah, fair, we could probably support a few or at least not load the vendored one when we are compatible. PRs accepted.

I think I got kind of annoyed working on this codebase and I'm not very satisfied with the current parsing I have because I didn't and still don't really know what I'm doing and it's all very ad-hoc. So I don't really have energy to add compat fixups and stuff like that, and it's kind of annoying trying to track a moving target. I'm hoping when JuliaLowering is stable that will be motivation to do a principled pass and maybe have a "fully correct" version of this package.

[oxinabox]

Fair.
I don't think it's a priority at all.

If I keep seeing 2 minute precompile time on CI I will make a PR.