feat: use workspace to manager projects

[Decodetalkers]

No description provided.

[bpevs]

oh lol I was just pulling the branch when you force-pushed. lmk when you think you're done making changes and I'll take a look. Thanks for making this update! I'm being too lazy 😭

fyi don't worry too much about any failing check; probably need to update action to denoland/setup-deno@v2; I can verify manually, and then I'll play around with fixing the gh action and make a release.

[Decodetalkers]

oh lol I was just pulling the branch when you force-pushed. lmk when you think you're done making changes and I'll take a look. Thanks for making this update! I'm being too lazy 😭

fyi don't worry too much about any failing check; probably need to update action to denoland/setup-deno@v2; I can verify manually, and then I'll play around with fixing the gh action and make a release.

all is done.. but seems there is a problem, that main.ts won't work with the workspace.. seems this pr should change to draft.. I will investigate more..

[Decodetalkers]

seems the workspace system in deno is such a drama.. only with the deno.json, esbuild won't know what it is relaying on..

[Decodetalkers]

I will ask the people of deno first then I can know how to fix this thing

[bpevs]

Ohhhhhhhhhh I remember this actually; the latest deno esbuild plugin doesn't support workspaces properly I think. I am currently using a different plugin with another project, but it's not public. mmmmm lemme try and summarize 1 sec

[bpevs]

https://github.com/twosaturdayscode/esbuild-deno-plugin

My other project looks something like this (intentionally using esbuild 0.24.x, just because 0.25 makes changes that break ctx.serve, and I've been to lazy to make a server):

import type { Format } from 'npm:esbuild@^0.24.2'
import * as esbuild from 'npm:esbuild@^0.24.2'
import { denoPlugins } from 'jsr:@duesabati/esbuild-deno-plugin@^0.2.6'
import { solidPlugin } from 'esbuild-plugin-solid'
import { resolve } from '@std/path'

const [denoResolver, denoLoader] = [...denoPlugins({
  configPath: resolve('../deno.json'),
})]

const options: esbuild.BuildOptions = {
  plugins: [],
  entryPoints: [{ in: './index.tsx', out: './index' }],
  outdir: './dist',
  bundle: true,
  platform: 'browser',
  format: 'esm' as Format,
  treeShaking: true,
}

options.plugins = [
  denoResolver,
  solidPlugin({ solid: { moduleName: 'npm:solid-js/web' } }),
  denoLoader,
]

const ctx = await esbuild.context(options)

const { host, port } = await ctx.serve({
  fallback: './index.html',
  host: '127.0.0.1',
  port: 2200,
  servedir: './',
})
console.log(`Serving at http://${host}:${port}`)

[Decodetalkers]

https://github.com/twosaturdayscode/esbuild-deno-plugin

My other project looks something like this (intentionally using esbuild 0.24.x, just because 0.25 makes changes that break ctx.serve, and I've been to lazy to make a server):

import type { Format } from 'npm:esbuild@^0.24.2'
import * as esbuild from 'npm:esbuild@^0.24.2'
import { denoPlugins } from 'jsr:@duesabati/esbuild-deno-plugin@^0.2.6'
import { solidPlugin } from 'esbuild-plugin-solid'
import { resolve } from '@std/path'

const [denoResolver, denoLoader] = [...denoPlugins({
  configPath: resolve('../deno.json'),
})]

const options: esbuild.BuildOptions = {
  plugins: [],
  entryPoints: [{ in: './index.tsx', out: './index' }],
  outdir: './dist',
  bundle: true,
  platform: 'browser',
  format: 'esm' as Format,
  treeShaking: true,
}

options.plugins = [
  denoResolver,
  solidPlugin({ solid: { moduleName: 'npm:solid-js/web' } }),
  denoLoader,
]

const ctx = await esbuild.context(options)

const { host, port } = await ctx.serve({
  fallback: './index.html',
  host: '127.0.0.1',
  port: 2200,
  servedir: './',
})
console.log(`Serving at http://${host}:${port}`)

but problem is that when we inside the folder of subproject , there is no place to mark they are using workspace.. I do not know how deno do that thing... But if we just pass the deno.json of subproject to esbuild , it won't know that it is a subproject I think.. so seems it is a hard thing..

[bpevs]

I think probably the directory structure ends up look like this, where configPath: resolve('../deno.json') is referencing the root /deno.json:

/
├── deno.json // new deno.json just declares workspace
├── main.ts
├── examples/
│     ├── preact/
│     │     ├── deno.json
│     │     └── mod.ts
│     └── barebones/
│           ├── deno.json
│           └── mod.ts
└── source/
      ├── deno.json // move the current root here
      └── mod.ts

{
  "workspace": ["./source", "./examples/preact", "./examples/barebones"]
}

[bpevs]

Ohhhhhh wait I see what you mean; because we're exporting the build script, workspace context breaks. hmmmm maybe using workspaces right now is kinda borked for that specific usecase.

I wonder if we could have user pass reference to ../deno.json (or w/e path) in cli args it could get around things?

[Decodetalkers]

Ohhhhhh wait I see what you mean; because we're exporting the build script, workspace context breaks. hmmmm maybe using workspaces right now is kinda borked for that specific usecase.

I wonder if we could have user pass reference to ../deno.json (or w/e path) in cli args it could get around things?

but seems it does not work.. even it reads the top deno.jsonc, it cannot know the lib path

[bpevs]

Hmmm gonna go to sleep now, but if you haven't figured it out, I'll take a look in a day or two when I find some free time.

To clarify, though, it looks like this pr is just implementing workspaces into bext, but I'm guessing the reason for the pr is that the build script isn't working when bext is integrated into a deno workspaces project (ala one bext-run project, and another sibling library)? Or is that something separate that is not explored here?

[bpevs]

Added in #12. Thanks for your help!