oscarotero

List of states to take into consideration

Network

• Online
  • Loading content
  • Content loaded (default)
  • Flaky network
  • Content failing to load
• Offline

oscarotero

6 persoas

Coordinadora (1 persoa)

• 16h/semana

documentación/catalogación (3 persoas):

• coordinadora
• Persoa 1: 4h/semana
• Persoa 2: 4h/semana

oscarotero

JSR feedback

I've been testing jsr with some packages. The experience was good in general but I would like to drop here my impressions, I hope you find them useful.

FastCheck

I used to avoid unnecessary typing in my TS code but seems that the new TypeScript checking for JSR (called FastCheck) is much more strict than the Deno default configuration (which was also quite strict). This made me think about one of the main flaws of Deno (in my opinion): The segmentation of the developer experience.

I had the same feeling before when Deno Deploy was released. Everybody assumed that you could deploy your Deno code until we realized that Deno Deploy is not the same as Deno CLI and doesn't support the same features. This difference between both runtimes has a reason (and it's understandable), but it breaks the expectation and introduces friction in the Deno ecosystem UX.

oscarotero

Package name: xxx (temporary name)

Update

xxx update: Updates the dependencies in the code. You can pass a list of patterns. For example:

• xxx update deps.ts Updates a file
• xxx update deps/*.ts Updates all files matching this pattern
• xxx update deps.ts deps/*.ts Updates all files matching several patterns

oscarotero

{
  "lock": false
}

oscarotero

const plugin: Deno.lint.Plugin = {
  // The name of your plugin. Will be shown in error output
  name: "my-plugin",
  // Object with rules. The property name is the rule name and
  // will be shown in the error output as well.
  rules: {
    "my-rule": {
      // Inside the `create(context)` method is where you'll put your logic.
      // It's called when a file is being linted.
      create(context) {