vite_plugin_deno_resolve icon indicating copy to clipboard operation
vite_plugin_deno_resolve copied to clipboard
verified publisher icon itsdouges

Umbrella issue for missing Deno features to enable this plugin to resolve url and npm specifiers

Open bartlomieju opened this issue 3 years ago • 8 comments

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.
View this repository on the Mend.io Web Portal.

Config Migration Needed

  • [ ] Select this checkbox to let Renovate create an automated Config Migration PR.

Deprecations / Replacements

[!WARNING] These dependencies are either deprecated or have replacements available:

Datasource Name Replacement PR?
maven org.slf4j:slf4j-log4j12 Available

[!WARNING] Renovate failed to look up the following dependencies: Failed to look up maven package net.sourceforge.saxon:saxon.

Files affected: pom.xml

Open

The following updates have all been created. To force a retry/rebase of any, click on a checkbox below.

  • [ ] Replace dependency org.slf4j:slf4j-log4j12 with org.slf4j:slf4j-reload4j 2.0.17
  • [ ] Update dependency com.jcabi:jcabi-aspects to v0.26.0
  • [ ] Update dependency com.jcabi:parent to v0.71.2
  • [ ] Update dependency com.qulice:qulice-maven-plugin to v0.25.0
  • [ ] Update dependency org.apache.maven.plugin-tools:maven-plugin-annotations to v3.15.2
  • [ ] Click on this checkbox to rebase all open PRs at once

PR Closed (Blocked)

The following updates are blocked by an existing closed PR. To recreate the PR, click on a checkbox below.

  • [ ] Update dependency org.apache.maven.doxia:doxia-sink-api to v2.0.0
  • [ ] Update dependency org.apache.maven.doxia:doxia-site-renderer to v2.0.0
  • [ ] Update dependency org.apache.maven.reporting:maven-reporting-api to v4.0.0
  • [ ] Update dependency org.apache.maven.reporting:maven-reporting-impl to v4.0.0
  • [ ] Update dependency com.jcabi.incubator:xembly to v0.32.2

Detected Dependencies

bundler (1)
jekyll/Gemfile (1)
  • jekyll '~>4.0'
github-actions (13)
.github/workflows/actionlint.yml (2)
  • actions/checkout v6
  • ubuntu 24.04
.github/workflows/codecov.yml (5)
  • actions/checkout v6
  • actions/setup-java v5
  • actions/cache v5
  • codecov/codecov-action v5
  • ubuntu 24.04
.github/workflows/copyrights.yml (3)
  • actions/checkout v6
  • yegor256/copyrights-action 0.0.12
  • ubuntu 24.04
.github/workflows/jekyll.yml (4)
  • actions/checkout v6
  • actions/cache v5
  • jeffreytse/jekyll-deploy-action v0.7.0
  • ubuntu 24.04
.github/workflows/markdown-lint.yml (3)
  • actions/checkout v6
  • DavidAnson/markdownlint-cli2-action v22.0.0
  • ubuntu 24.04
.github/workflows/mvn.yml (3)
  • actions/checkout v6
  • actions/setup-java v5
  • actions/cache v5
.github/workflows/pdd.yml (2)
  • actions/checkout v6
  • ubuntu 24.04
.github/workflows/python-flake8-lint.yml (4)
  • actions/checkout v6
  • actions/setup-python v6
  • ubuntu 24.04
  • python 3.14
.github/workflows/reuse.yml (3)
  • actions/checkout v6
  • fsfe/reuse-action v6
  • ubuntu 24.04
.github/workflows/typos.yml (3)
  • actions/checkout v6
  • crate-ci/typos v1.42.0
  • ubuntu 24.04
.github/workflows/up.yml (3)
  • actions/checkout v6
  • peter-evans/create-pull-request v8
  • ubuntu 24.04
.github/workflows/xcop.yml (2)
  • actions/checkout v6
  • ubuntu 24.04
.github/workflows/yamllint.yml (3)
  • actions/checkout v6
  • ibiqlik/action-yamllint v3
  • ubuntu 24.04
maven (9)
pom.xml (17)
  • com.jcabi:parent 0.70.0 → [Updates: 0.71.2]
  • org.projectlombok:lombok 1.18.42
  • org.antlr:antlr4-runtime 4.13.2
  • commons-io:commons-io 2.21.0
  • com.jcabi:jcabi-log 0.24.3
  • com.jcabi:jcabi-xml 0.35.0
  • com.jcabi:jcabi-manifests 2.2.0
  • javax.servlet:javax.servlet-api 4.0.1
  • com.jcabi:jcabi-matchers 1.8.0
  • net.sourceforge.saxon:saxon 9.1.0.8
  • net.sourceforge.saxon:saxon 9.1.0.8
  • ch.qos.reload4j:reload4j 1.2.26
  • org.slf4j:slf4j-log4j12 2.0.17 → [Updates: 2.0.17]
  • junit:junit 4.13.2
  • org.junit.vintage:junit-vintage-engine 6.0.2
  • org.junit.jupiter:junit-jupiter-params 6.0.2
  • org.mockito:mockito-core 5.21.0
requs-core/pom.xml (15)
  • com.jcabi.incubator:xembly 0.26.2 → [Updates: 0.32.2]
  • com.jcabi:jcabi-aspects 0.24.1 → [Updates: 0.26.0]
  • com.jcabi:jcabi-immutable 1.5
  • javax.validation:validation-api 2.0.1.Final
  • com.vladsch.flexmark:flexmark 0.64.8
  • com.vladsch.flexmark:flexmark-util-data 0.64.8
  • com.vladsch.flexmark:flexmark-util-ast 0.64.8
  • commons-codec:commons-codec 1.20.0
  • com.google.guava:guava 33.5.0-jre
  • org.apache.commons:commons-lang3 3.20.0
  • org.apache.commons:commons-text 1.15.0
  • net.sourceforge.plantuml:plantuml 8059
  • com.jcabi.incubator:phandom 0.4
  • nl.geodienstencentrum.maven:sass-maven-plugin 3.7.2
  • com.qulice:qulice-maven-plugin 0.24.4 → [Updates: 0.25.0]
requs-exec/pom.xml (6)
  • net.sf.jopt-simple:jopt-simple 6.0-alpha-3
  • com.jcabi:jcabi-xml 0.35.0
  • com.jcabi:jcabi-matchers 1.8.0
  • org.hamcrest:hamcrest-core 3.0
  • org.hamcrest:hamcrest-library 3.0
  • com.qulice:qulice-maven-plugin 0.24.4 → [Updates: 0.25.0]
requs-exec/src/it/compiles-simple-syntax/pom.xml (1)
  • org.codehaus.mojo:exec-maven-plugin 3.6.3
requs-maven-plugin/pom.xml (15)
  • com.jcabi:jcabi-maven-slf4j 0.12.2
  • org.apache.maven.reporting:maven-reporting-api 4.0.0-M2 → [Updates: 4.0.0]
  • org.apache.maven.reporting:maven-reporting-impl 4.0.0-M2 → [Updates: 4.0.0]
  • org.apache.maven:maven-plugin-api 3.9.12
  • org.apache.maven:maven-core 3.9.12
  • org.apache.maven.plugin-tools:maven-plugin-annotations 3.6.4 → [Updates: 3.15.2]
  • org.apache.maven.plugin-testing:maven-plugin-testing-harness 3.4.0
  • org.apache.maven:maven-compat 3.9.12
  • org.apache.maven.doxia:doxia-sink-api 2.0.0-M3 → [Updates: 2.0.0]
  • org.apache.maven.doxia:doxia-site-renderer 2.0.0-M3 → [Updates: 2.0.0]
  • org.hamcrest:hamcrest-core 3.0
  • org.hamcrest:hamcrest-library 3.0
  • com.jcabi:jcabi-matchers 1.8.0
  • com.jcabi:jcabi-xml 0.35.0
  • com.qulice:qulice-maven-plugin 0.24.4 → [Updates: 0.25.0]
requs-maven-plugin/src/it/absent-input-dir/pom.xml
requs-maven-plugin/src/it/broken-spec/pom.xml
requs-maven-plugin/src/it/report-in-site/pom.xml (1)
  • org.apache.maven.plugins:maven-site-plugin 3.21.0
requs-maven-plugin/src/it/simple-compile/pom.xml
  • [ ] Check this box to trigger a request for Renovate to run again on this repository

bartlomieju avatar Dec 22 '22 22:12 bartlomieju

Thanks mate! So I think remote imports should work pretty well currently (would love second eyes on the current implementation however). This is a good example of another implementation (for esbuild) for remote imports as well: https://github.com/lucacasonato/esbuild_deno_loader that I've been taking inspiration from.

For resolving npm specifiers we're going to need some work. Top of the list is:

  • Resolving cache location for a npm specifier in deno info

From there we'll be unblocked to continue, one thing I'm unsure of is the complexity of resolving dependencies inside a npm specifier import. For remote (deno native) imports it's just iterate through the dependency array from deno info which is simple enough. Hopefully npm specifiers would be similar.

Other thoughts:

  • It's possible to get the current deno exec with Deno.execPath(). Is there an API for getting the current import_map path? That would be useful to transparently pass it on without needing a config option for it.
  • Should all modules try and be resolved through deno info? Currently the plugin only tries to resolve remote https imports.
  • Only remote modules should be passed to deno cache, right? What happens if you pass local ones? Would that be appropriate for getting the emit location I guess? 🤔 Any benefit or just leave bundlers to it?
  • How do we teach TypeScript/deno emit to use the Deno cache version of React? I'm hoping we could use the config and it would work as expected? E.g. in deno.jsonc:
  "compilerOptions": {
    "jsx": "react-jsx",
    "jsxImportSource": "npm:[email protected]",
    "lib": ["dom", "dom.iterable", "dom.asynciterable", "deno.ns"],
    "types": ["vite/client"]
  }

itsdouges avatar Dec 23 '22 06:12 itsdouges

It's possible to get the current deno exec with Deno.execPath(). Is there an API for getting the current import_map path? That would be useful to transparently pass it on without needing a config option for it.

No, currently there's no way to get it - there are some issues asking to add it, but I'm a bit reluctant until this is agreed with WICG proposal.

Should all modules try and be resolved through deno info? Currently the plugin only tries to resolve remote https imports.

I think it makes sense, though there might be some edge cases where it's not desirable - I guess we will have to try and see if we come up with any situations where it's not desirable.

Only remote modules should be passed to deno cache, right? What happens if you pass local ones? Would that be appropriate for getting the emit location I guess? 🤔 Any benefit or just leave bundlers to it?

Not sure, local modules are only transpiled by Deno, but they are not cached (ie. the original source is always read from the specified local location).

How do we teach TypeScript/deno emit to use the Deno cache version of React? I'm hoping we could use the config and it would work as expected? E.g. in deno.jsonc:

I believe Deno uses react jsx transform by default, so it probably doesn't need any changes to work.

bartlomieju avatar Dec 23 '22 15:12 bartlomieju

@bartlomieju Hey mate when working on resolving (cache + info) local modules it doesn't work if you try to import CSS modules, e.g:

This works, I can get an emit: https://github.com/itsdouges/vite_deno_resolve/blob/13b9d58e8c67f7d1eb0d1cbbef1ff9e06a0cdb19/examples/url/local.tsx

import React, { useState } from 'https://esm.sh/[email protected]';
import { titleCase } from 'https://deno.land/x/[email protected]/mod.ts';

This doesn't work, as it imports CSS: https://github.com/itsdouges/vite_deno_resolve/blob/13b9d58e8c67f7d1eb0d1cbbef1ff9e06a0cdb19/examples/url/main.tsx

import React from 'https://esm.sh/[email protected]';
import { createRoot } from 'https://esm.sh/[email protected]/client';
import { App } from './local.tsx';
import './style.css';

Removing the import gets it working.

Would it be possible for Deno to noop this kinds of imports? So instead of throwing it just prints it out as is? This would allow us to get Deno to resolve local modules, and transform TypeScript to JavaScript (all with Deno! So less surprises with interop).

You can see a spike here https://github.com/itsdouges/vite_plugin_deno_resolve/compare/local-modules?expand=1 - currently has caching issues.

itsdouges avatar Dec 28 '22 02:12 itsdouges

Would it be possible for Deno to noop this kinds of imports? So instead of throwing it just prints it out as is? This would allow us to get Deno to resolve local modules, and transform TypeScript to JavaScript (all with Deno! So less surprises with interop).

Not really, that would break a lot of invariants Deno has about imports. There are two ways forward here - a) this import gets transpiled by Vite (which I believe Vite maintainers mentioned to me); b) we should work on adding CSS support to Deno (it would be a big endeavor though)

bartlomieju avatar Dec 28 '22 09:12 bartlomieju

There are other static asset style imports that could exist in a frontend app though, such as images and fonts. Vite handling transpilation of local assets is definitely the way forward for now, but I imagine it'd make more sense to have it use the tsconfig from deno.json? Would be easy for some confusion to occur.

itsdouges avatar Dec 28 '22 09:12 itsdouges

But Node.js can't import those files either without them being transpiled into Js. I'm not sure I understand what tsconfig would be here. Could you elaborate?

bartlomieju avatar Dec 28 '22 10:12 bartlomieju

Taking a step back - my assumption was Deno uses the config in deno.json for the transpilation from tsx -> js, so for example if I update compilerOptions.jsxImportSouce to "foo", then it imports jsx-runtime from the foo package instead of react. Is this a correct assumption?

If it is - then my point is that if Deno doesn't transpile local modules it'll be friction as there will be two or more configs for this now, one for Deno types, one for Vite transpilation. This wouldn't be worse than the current world in Node/Vite iirc but Deno has a chance here to really stream line it end to end.

If it isn't - how does it work?

itsdouges avatar Dec 28 '22 10:12 itsdouges

Ah yes, that's the case according to https://deno.land/[email protected]/advanced/jsx_dom/jsx#using-jsx-import-source-in-a-configuration-file. This can be also overridden via an import map. Maybe we could punt on it for now and get some basic example working that doesn't override this setting?

bartlomieju avatar Dec 28 '22 10:12 bartlomieju