Add artist website and portfolio files with LFS

These browsers have bugs that occasionally cause typed array comparisons
to pass when they should fail, or vice versa:

* for...in loops sometimes omit keys, such that two typed arrays with
  different lengths appear to have the same set of keys.
* Typed arrays sometimes have mulitple undefined keys (which is to say that
  the key itself is undefined). Two typed arrays with identical length and
  contents can compare unequal because of the spurious undefined keys.)

Those problems could be avoided by comparing keys 0...length-1 rather than
the actual set of exposed keys, but that would be a pretty nasty breaking
change for anyone whose code tacks extra properties onto typed arrays. So
far these bugs haven't been seen in anything newer than FF 128. Since the
affected browsers are all past end of life, the most sensible thing is to
just stop testing against them.

.circleci/config.yml

@@ -0,0 +1,156 @@
+# Run tests against supported Node versions, and (except for pull requests)
+# against supported browsers that are available on Saucelabs.
+
+version: 2.1
+
+orbs:
+  win: circleci/windows@5.0.0
+
+executors:
+  node24:
+    docker:
+      - image: cimg/node:24.0.0
+    working_directory: ~/workspace
+  node22:
+    docker:
+      - image: cimg/node:22.0.0
+    working_directory: ~/workspace
+  node20:
+    docker:
+      - image: cimg/node:20.0.0
+    working_directory: ~/workspace
+
+jobs:
+  build:
+    parameters:
+      executor:
+        type: executor
+    executor: << parameters.executor >>
+    steps:
+      - checkout
+      - run:
+          name: Report Node and NPM versions
+          command: echo "Using Node $(node --version) and NPM $(npm --version)"
+      - run:
+          name: Install dependencies
+          command: npm install
+      - run:
+          name: Build
+          command: npm run build
+      - persist_to_workspace:
+          root: .
+          paths:
+            - .
+
+  test_node: &test_node
+    parameters:
+      executor:
+        type: executor
+    executor: << parameters.executor >>
+    steps:
+      - attach_workspace:
+          at: .
+      - run:
+          name: Report Node and NPM versions
+          command: echo "Using Node $(node --version) and NPM $(npm --version)"
+      - run:
+          name: Run tests
+          command: npm test
+
+  test_win:
+    executor:
+      name: win/default
+      shell: bash.exe
+    steps:
+      - checkout
+      - run:
+          name: Install Node.js
+          command: nvm install 20.0.0 && nvm use 20.0.0
+      - run:
+          name: Report Node and NPM versions
+          command: echo "Using Node $(node --version) and NPM $(npm --version)"
+      - run:
+          name: Install dependencies
+          command: npm install
+      - run:
+          name: Build
+          command: npm run build
+      - run:
+          name: Run tests
+          command: npm test
+
+  test_parallel: &test_parallel
+    parameters:
+      executor:
+        type: executor
+    executor: << parameters.executor >>
+    steps:
+      - attach_workspace:
+          at: .
+      - run:
+          name: Report Node and NPM versions
+          command: echo "Using Node $(node --version) and NPM $(npm --version)"
+      - run:
+          name: Run tests in parallel
+          command: npm run test:parallel
+
+  test_browsers: &test_browsers
+    executor: node20
+    steps:
+      - attach_workspace:
+          at: .
+      - run:
+          name: Install Sauce Connect
+          command: |
+            tmpdir=$(mktemp -d)
+            cd "$tmpdir"
+            curl https://saucelabs.com/downloads/sauce-connect/5.2.2/sauce-connect-5.2.2_linux.x86_64.tar.gz | tar zxf -
+            chmod +x sc
+            mkdir ~/workspace/bin
+            cp sc ~/workspace/bin
+            echo "Sauce Connect version info:"
+            ~/workspace/bin/sc version
+      - run:
+          name: Run tests
+          command: |
+            # Do everything in one step because Sauce Connect won't exit
+            # cleanly if we kill it from a different step than it started in.
+
+            export PATH=$PATH:$HOME/workspace/bin
+            export SAUCE_TUNNEL_NAME=$CIRCLE_WORKFLOW_JOB_ID
+            scripts/start-sauce-connect
+            set +o errexit
+            scripts/run-sauce-browsers
+            exitcode=$?
+            set -o errexit
+            scripts/stop-sauce-connect
+            exit $exitcode
+
+workflows:
+  version: 2
+
+  push:
+    jobs:
+      - build:
+          matrix:
+            parameters:
+              executor: [node20, node22, node24]
+      - test_node:
+          matrix:
+            parameters:
+              executor: [node20, node22, node24]
+          requires:
+            - build-<< matrix.executor >>
+      - test_parallel:
+          matrix:
+            parameters:
+              executor: [node20, node22, node24]
+          requires:
+            - build-<< matrix.executor >>
+      - test_browsers:
+          requires:
+             - build-node20
+          filters:
+            branches:
+              ignore: /pull\/.*/ # Don't run on pull requests.
+      - test_win

.editorconfig

@@ -0,0 +1,8 @@
+[*]
+charset = utf-8
+end_of_line = lf
+insert_final_newline = true
+
+[*.{js,mjs,json,sh,yml}]
+indent_style = space
+indent_size = 2

.gitattributes

@@ -0,0 +1,7 @@
+* text=auto eol=lf
+*.png filter=lfs diff=lfs merge=lfs -text
+*.mp4 filter=lfs diff=lfs merge=lfs -text
+*.mov filter=lfs diff=lfs merge=lfs -text
+*.jpg filter=lfs diff=lfs merge=lfs -text
+*.pdf filter=lfs diff=lfs merge=lfs -text
+*.docx filter=lfs diff=lfs merge=lfs -text

.github/CONTRIBUTING.md

@@ -0,0 +1,112 @@
+# Contributing to Jasmine
+
+We welcome your contributions! Thanks for helping make Jasmine a better project
+for everyone. If you want to contribute but don't know what to work on, 
+[issues tagged help needed](https://github.com/issues?q=is%3Aopen+is%3Aissue+org%3Ajasmine+label%3A%22help+needed%22+)
+should have enough detail to get started.
+
+## Before Submitting a Pull Request
+
+1. Ensure all specs are green in browsers *and* node.
+   * Use `npm test` to test in Node.
+   * Use `npm run serve` to test in browsers.
+2. Fix any eslint or prettier errors reported at the end of `npm test`. Prettier
+   errors can be automatically fixed by running `npm run cleanup`.
+3. Build `jasmine.js` with `npm run build` and run all specs again. This
+   ensures that your changes self-test well.
+5. Revert your changes to `jasmine.js` and `jasmine-html.js`. When we accept 
+   your pull request, we will generate these files as a separate commit and
+   merge the entire branch into master.
+
+We only accept green pull requests. If you see that the CI build failed, please
+fix it. Feel free to ask for help if you're stuck.
+
+## Background
+
+### Directory Structure
+
+* `/src` contains all of the source files
+    * `/src/core` - generic source files
+    * `/src/html` - browser-specific files
+    * `/src/boot` - sources for boot files (see below)
+* `/spec` contains all of the tests
+    * mirrors the source directory
+    * there are some additional files
+* `/lib` contains the compiled copy of Jasmine. This is used to self-test and
+  distributed as the `jasmine-core` Node, and Ruby packages.
+
+### Self-testing
+
+Jasmine tests itself. The files in `lib` are loaded first, defining the reference `jasmine`. Then the files in `src` are loaded, defining the reference `jasmineUnderTest`. So there are two copies of the code loaded under test.
+
+The tests should always use `jasmineUnderTest` to refer to the objects and functions that are being tested. But the tests can use functions on `jasmine` as needed. _Be careful how you structure any new test code_. Copy the patterns you see in the existing code - this ensures that the code you're testing is not leaking into the `jasmine` reference and vice-versa.
+
+### `boot0.js` and `boot1.js`
+
+These files file does all of the setup necessary for Jasmine to work in a
+browser. They load all of the code, create an `Env`, attach the global
+functions, and build the reporter. It also sets up the execution of the 
+`Env` - for browsers this is in `window.onload`. While the default in `lib`
+is appropriate for browsers, projects may wish to customize this file.
+
+### Compatibility
+
+Jasmine runs in both Node and a variety of browsers. See the README for the
+list of currently supported environments.
+
+## Development
+
+All source code belongs in `src/`. The `core/` directory contains the bulk of Jasmine's functionality. This code should remain browser- and environment-agnostic. If your feature or fix cannot be, as mentioned above, please degrade gracefully. Any code that depends on a browser (specifically, it expects `window` to be the global or `document` is present) should live in `src/html/`.
+
+### Install Dev Dependencies
+
+Jasmine Core relies on Node.js.
+
+To install the Node dependencies, you will need Node.js and npm.
+
+    $ npm install
+
+...will install all of the node modules locally. Now run
+
+    $ npm test
+
+...you should see tests run and eslint checking formatting.
+
+### How to write new Jasmine code
+
+Or, How to make a successful pull request
+
+* _Do not change the public interface_. Lots of projects depend on Jasmine and
+  if you aren't careful you'll break them.
+* _Be environment agnostic_. Some people run their specs in browsers, others in
+  Node. Jasmine should support them all as much as possible.
+* _Be browser agnostic_ - if you must rely on browser-specific functionality, 
+  please write it in a way that degrades gracefully.
+* _Write specs_ - Jasmine's a testing framework. Don't add functionality 
+  without test-driving it.
+* _Write code in the style of the rest of the repo_ - Jasmine should look like
+  a cohesive whole. 
+* _Ensure the *entire* test suite is green_ in all the big browsers, Node, and
+  ESLint/Prettier. Your contribution shouldn't break Jasmine for other users.
+
+Follow these tips and your pull request, patch, or suggestion is much more likely to be integrated.
+
+### Running Specs
+
+Be sure to run the tests in at least one supported Node version and at least a
+couple of supported browsers. To run the tests in Node, simply use `npm test`
+as described above. To run the tests in a browser, run `npm run serve` and then
+visit `http://localhost:8888`.
+
+If you have the necessary Selenium drivers installed (e.g. geckodriver or 
+chromedriver), you can also use Jasmine's CI tooling: 
+
+    $ JASMINE_BROWSER=<name of browser> npm run ci
+
+### Submitting a Pull Requeset
+
+Once you've done the steps listed under "Before Submitting a Pull Request"
+above, you can submit a pull request via the 
+[standard GitHub process](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request).
+TL;DR: Fork the repository, push your work up to your fork, and create a PR from
+there.

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -0,0 +1,95 @@
+name: Bug Report
+description: I think I've found a bug in Jasmine
+labels: ["bug report"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for taking the time to report a bug. Please follow these steps first.
+
+        ## Troubleshooting
+        Please take the time to rule out issues with your code or third party libraries before filing a bug report. If you are reporting an error, try to determine whether the error is coming from Jasmine, another library, or your own code.
+
+        Check the [FAQ](https://jasmine.github.io/pages/faq.html) and any other relevant [documentation](https://jasmine.github.io/pages/docs_home.html) to see if your issue has already been addressed.
+
+        ## Special troubleshooting steps for asynchronous scenarios
+        If the issue has to do with testing asynchronous code, please read the [async tutorial](https://jasmine.github.io/tutorials/async) and the [async section of the FAQ](https://jasmine.github.io/pages/faq.html#async). In particular, check for the following common errors:
+
+        * Are you trying to write a synchronous test for asynchronous code?
+        * Does the test signal completion before the code under test finishes?
+        * Do expectations run before the code that they're trying to verify?
+
+        ## Try the latest version of Jasmine
+        If at all possible, upgrade to the latest versions of `jasmine-core` and any other relevant packages (e.g. `jasmine`, `jasmine-browser-runner`). If you can't do that, please check the [release notes](https://github.com/jasmine/jasmine/tree/main/release_notes) for all newer versions to make sure that the bug hasn't already been fixed.
+
+        ## Explain how to reproduce the bug
+        
+        **Working steps to reproduce are required for all bug reports.** Please help us help you by creating complete but minimal instructions for reproducing the bug.
+        
+        The steps to reproduce could be:
+        
+        * A code snippet that reproduces the problem when run by itself in a newly generated empty `jasmine` or `jasmine-browser-runner` project, or in the standalone distribution.
+        * A set of steps that reproduce the problem when followed exactly as they're written in an empty directory.
+        * A link to a Git repository or zip/tar file containing a [minimal, reproducible example](https://stackoverflow.com/help/minimal-reproducible-example). This option is required for all bugs that can only be reproduced with third-party libraries, including Angular and Karma.
+
+        Please **test your steps** by starting with an empty directory and following them exactly as they're written. Bug reports with steps to reproduce that are unclear, don't work, or include an unreasonable amount of extraneous code will likely be closed.
+        
+  - type: textarea
+    id: steps-to-reproduce
+    attributes:
+      label: Steps to Reproduce
+    validations:
+      required: true
+  - type: textarea
+    id: expected-behavior
+    attributes:
+      label: Expected Behavior
+      description: What do you think should have happened?
+    validations:
+      required: true
+  - type: textarea
+    id: actual-behavior
+    attributes:
+      label: Actual Behavior
+      description: What happened instead?
+    validations:
+      required: true
+  - type: textarea
+    id: possible-solution
+    attributes:
+      label: Possible Solution
+      description: This is optional, but if you have an idea for how to fix the bug we'd like to hear it.
+  - type: textarea
+    id: context
+    attributes:
+      label: Context
+      description: How has this issue affected you? What are you trying to accomplish? By providing context, you can help us come up with a solution that is most useful in the real world.
+  - type: input
+    id: jasmine-core-version
+    attributes:
+      label: jasmine-core version
+    validations:
+      required: true
+  - type: textarea
+    id: other-versions
+    attributes:
+      label: Versions of other relevant packages
+      placeholder: |
+        jasmine-browser-runner 1.2.0
+        fancy-reporter 132.4.8
+
+  - type: input
+    id: browser-or-node-version
+    attributes:
+      label: Node.js and/or browser version
+      placeholder: E.g. "node 16.2.0" or "Safari 15"
+    validations:
+      required: true
+  - type: input
+    id: os
+    attributes:
+      label: Operating System
+      placeholder: E.g. "Windows 10", "MacOS 12.5", "MCC Interim Linux 0.99.p8"
+    validations:
+      required: true
+

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,17 @@
+blank_issues_enabled: false
+contact_links:
+  - name: Questions, requests for help, etc
+    url: https://github.com/jasmine/jasmine/discussions/new/choose
+    about: Please start a discussion.
+  - name: Issues with the `jasmine` CLI
+    url: https://github.com/jasmine/jasmine-npm/issues
+    about: Please create issues related to the `jasmine` package in its repository.
+  - name: Issues with jasmine-browser-runner
+    url: https://github.com/jasmine/jasmine-browser-runner/issues
+    about: Please create issues related to the `jasmine-browser-runner` package in its repository.
+  - name: Documentation issues
+    url: https://github.com/jasmine/jasmine.github.io/issues
+    about: Please create documentation issues in the docs repository.
+  - name: TypeScript issues
+    url: https://github.com/DefinitelyTyped/DefinitelyTyped/discussions
+    about: Please create issues related to TypeScript compilation errors or other problems with type definitions at DefinitelyTyped.

.github/ISSUE_TEMPLATE/feature_proposal.yml

@@ -0,0 +1,31 @@
+name: Feature Proposal
+description: I'd like to propose a new feature
+labels: ["feature request"]
+body:
+  - type: markdown
+    attributes:
+      value: Thanks for taking the time to propose a new feature. Although Jasmine is mostly feature complete, we're always open to hearing new ideas.
+  - type: textarea
+    id: description
+    attributes:
+      label: Feature Proposal
+    validations:
+      required: true
+  - type: textarea
+    id: context
+    attributes:
+      label: Context
+      description: How would this feature be useful to you? What are you trying to accomplish? By providing context, you can help us come up with a solution that is most useful in the real world.
+    validations:
+      required: true
+  - type: textarea
+    id: example
+    attributes:
+      label: Example
+      description: If you're proposing a new API or something similar, please show an example of how it would be used.
+      render: JavaScript
+  - type: textarea
+    id: other-info
+    attributes:
+      label: Other Information
+      description: Anything else that you think would be helpful.

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,30 @@
+<!--- Provide a general summary of your changes in the Title above -->
+
+## Description
+<!--- Describe your changes in detail -->
+
+## Motivation and Context
+<!--- Why is this change required? What problem does it solve? -->
+<!--- If it fixes an open issue, please link to the issue here. -->
+
+## How Has This Been Tested?
+<!--- Please describe in detail how you tested your changes. -->
+<!--- Include details of your testing environment, and the tests you ran to -->
+<!--- see how your change affects other areas of the code, etc. -->
+
+## Types of changes
+<!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
+- [ ] Bug fix (non-breaking change which fixes an issue)
+- [ ] New feature (non-breaking change which adds functionality)
+- [ ] Breaking change (fix or feature that would cause existing functionality to change)
+
+## Checklist:
+<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
+<!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
+- [ ] My code follows the code style of this project.
+- [ ] My change requires a change to the documentation.
+- [ ] I have updated the documentation accordingly.
+- [ ] I have read the [**CONTRIBUTING**](https://github.com/jasmine/jasmine/blob/main/.github/CONTRIBUTING.md) guide.
+- [ ] I have added tests to cover my changes.
+- [ ] All new and existing tests passed.
+

.github/workflows/safari.yml

@@ -0,0 +1,23 @@
+name: Test in latest available Safari
+
+on:
+  push:
+  pull_request:
+  workflow_dispatch:
+  schedule:
+    - cron: '0 0 * * *'
+jobs:
+  build:
+    runs-on: macos-latest
+
+    steps:
+    - name: Report Safari version
+      run: osascript -e 'get version of application "Safari"'
+    - uses: actions/checkout@v4
+    - name: Use Node.js 22.x
+      uses: actions/setup-node@v4
+      with:
+        node-version: 22.x
+    - run: npm install
+    - run: npm run build
+    - run: JASMINE_BROWSER=safari npm run ci

.gitignore

@@ -1,2 +1,26 @@
 .idea/
 .svn/
+.DS_Store
+site/
+.bundle/
+.pairs
+.rvmrc
+.ruby-gemset
+.ruby-version
+*.gem
+.bundle
+tags
+Gemfile.lock
+package-lock.json
+yarn.lock
+pkg/*
+.sass-cache/*
+src/html/.sass-cache/*
+node_modules/
+sauce_connect.log
+*.swp
+build/
+dist
+nbproject/
+*.iml
+.envrc

.prettierrc

@@ -0,0 +1,3 @@
+{
+  "singleQuote": true
+}

AGENTS.md

@@ -0,0 +1,48 @@
+# Jasmine Core Development Notes
+
+## Architecture
+
+- This is the main jasmine-core repository, a JavaScript BDD testing framework
+- **Directory structure**:
+  - `src/` - source code
+    - `src/core/` - environment-agnostic core functionality
+    - `src/html/` - browser-specific code
+    - `src/boot/` - boot files for browser setup
+  - `spec/` - tests, mirrors the src directory structure
+  - `lib/` - compiled distribution files (built, not checked in modified)
+
+## Key Development Commands
+
+- `npm install` - install dependencies
+- `npm test` - run all tests in Node.js + lint + prettier check
+- `npm run test:parallel` - run tests in parallel
+- `npm run build` - build distribution to `/lib`
+- `npm run cleanup` - auto-fix prettier errors
+- `npm run serve` - serve tests for browser testing at http://localhost:8888
+- `JASMINE_BROWSER=<name> npm run ci` - run browser tests via Selenium
+
+## Before submitting PR
+
+1. Run tests in Node.js AND browsers: `npm test` and `npm run serve`
+2. Fix any eslint/prettier errors: `npm run cleanup`
+3. Build `lib/` with `npm run build` and re-test
+4. Revert changes to built files in `lib/` - maintainers will rebuild when merging
+
+## Testing Conventions
+
+- Jasmine self-tests: `lib/jasmine-core.js` provides `jasmine` (runner), `src/` provides `jasmineUnderTest` (code under test)
+- Always use `jasmineUnderTest` for objects/functions being tested
+
+## Coding Conventions
+
+- Single quotes, semicolons required
+- Curly braces required for all control statements
+- ECMA 2022 syntax, commonjs modules
+- Core code must stay environment-agnostic:
+  - Keep browser-specific code in `src/html/`
+  - Degrade gracefully when environment-specific features aren't available
+
+## Supported Environments
+
+- Node: 20, 22, 24
+- Browsers: Safari 26+, Chrome/Firefox/Edge (evergreen)

CODE_OF_CONDUCT.md

@@ -0,0 +1,46 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at jasmine-maintainers@googlegroups.com. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/

LICENSE

@@ -1,4 +1,5 @@
-Copyright (c) 2008 Pivotal Labs
+Copyright (c) 2008-2019 Pivotal Labs
+Copyright (c) 2008-2026 The Jasmine developers
 
 Permission is hereby granted, free of charge, to any person obtaining
 a copy of this software and associated documentation files (the
@@ -17,4 +18,4 @@ MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
 NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
 LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
 OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
-WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

README.markdown

@@ -1,489 +0,0 @@
-Jasmine
-=======
-**A JavaScript Testing Framework**
-
-Quick Start
-----------
-
-1. Get the latest release from the [downloads page](http://github.com/pivotal/jasmine/downloads).
-2. Open `example/example_runner.html` in your favorite browser.
-
-For running within a Ruby environment, including automated execution with Selenium, please use
-the [jasmine-ruby gem](http://github.com/pivotal/jasmine-ruby).
-
-Releases
-----------
-0.10.0 [[download]](http://cloud.github.com/downloads/pivotal/jasmine/jasmine-0.10.0.zip)
-
-0.9.0 [[download]](http://github.com/pivotal/jasmine/zipball/0.9.0)
-
-0.8.0 [[download]](http://github.com/pivotal/jasmine/zipball/0.8.0)
-
-### Which Release Should I Use?
-
-Please use the latest version unless you have a good reason not to. Some of this documentation may not be applicable to older versions.
-
-Pull Requests
-----------
-We welcome your contributions! Jasmine is currently maintained by Davis Frank ([infews](http://github.com/infews)), Rajan Agaskar ([ragaskar](http://github.com/ragaskar)), and Christian Williams ([Xian](http://github.com/Xian)). You can help us by removing all other recipients from your pull request.
-
-
-Why Another JavaScript TDD/BDD Framework?
------------
-
-There are some great JavaScript testing frameworks out there already, so why did we write another?
-
-None of the existing frameworks quite worked the way we wanted. Many only work from within a browser. Most don't support testing asynchronous code like event callbacks. Some have syntax that's hard for JS developers or IDEs to understand.
-
-So we decided to start from scratch.
-
-Enter Jasmine
-------------
-
-Jasmine is our dream JavaScript testing framework. It's heavily influenced by, and borrows the best parts of, ScrewUnit, JSSpec, [JSpec](http://github.com/visionmedia/jspec/tree/master), and of course RSpec.
-
-Jasmine was designed with a few principles in mind. We believe that a good JavaScript testing framework:
-
-* should not be tied to any browser, framework, platform, or host language.
-* should have idiomatic and unsurprising syntax.
-* should work anywhere JavaScript can run, including browsers, servers, phones, etc.
-* shouldn't intrude in your application's territory (e.g. by cluttering the global namespace).
-* should play well with IDEs (e.g. test code should pass static analysis).
-
-Some of our goals while writing Jasmine:
-
-* it should encourage good testing practices.
-* it should integrate easily with continuous build systems.
-* it should be simple to get started with.
-
-The result is Jasmine, and we love test-driving our code with it. Enjoy.
-
-How To
-------
-
-There is a simple example of how to use Jasmine in the /example directory.  But here's more information.
-
-### Specs
-
-Each spec is, naturally, a JavaScript function.  You tell Jasmine about this spec with a call to `it()` with a string and the function.  The string is a description that will be helpful to you when reading a report.
-
-    it('should be a test', function () {
-      var foo = 0;
-      foo++;
-    });
-
-### Expectations
-
-Within your spec you will want to express expectations about the behavior of your application code.  These are made with the `expect()` function and expectation matchers, like this:
-
-    it('should be a test', function () {
-      var foo = 0;            // set up the world
-      foo++;                  // call your application code
-
-      expect(foo).toEqual(1); // passes because foo == 1
-    });
-
-Results of the expectations are logged for later for reporting.
-
-#### Expectation Matchers
-
-Jasmine has several built-in matchers.  Here are a few:
-
->`expect(x).toEqual(y);` compares objects or primitives `x` and `y` and passes if they are equivalent
->
->`expect(x).toMatch(pattern);` compares `x` to string or regular expression `pattern` and passes if they match
->
->`expect(x).toBeDefined();` passes if `x` is not `undefined`
->
->`expect(x).toBeNull();` passes if `x` is `null`
->
->`expect(x).toBeTruthy();` passes if `x` evaluates to true
->
->`expect(x).toBeFalsy();` passes if `x` evaluates to false
->
->`expect(x).toContain(y);` passes if array or string `x` contains `y`
-
-Every matcher's criteria can be inverted by prepending `.not`:
-
->`expect(x).not.toEqual(y);` compares objects or primitives `x` and `y` and passes if they are *not* equivalent
-
-#### Writing New Matchers
-
-We've provided a small set of matchers that cover many common situations. However, we recommend that you write custom matchers when you want to assert a more specific sort of expectation. Custom matchers help to document the intent of your specs, and can help to remove code duplication in your specs.
-
-It's extremely easy to create new matchers for your app. A matcher function receives the actual value as `this.actual`, and zero or more arguments may be passed in the function call. The function should return `true` if the actual value passes the matcher's requirements, and `false` if it does not.
-
-Here's the definition of `toBeLessThan()`:
-
-    toBeLessThan: function(expected) {
-      return this.actual < expected;
-    };
-
-To add the matcher to your suite, call `this.addMatchers()` from within a `before` or `it` block. Call it with an object mapping matcher name to function:
-
-    beforeEach(function() {
-      this.addMatchers({
-        toBeVisible: function() { return this.actual.isVisible(); }
-      });
-    });
-
-### Suites
-
-Specs are grouped in Suites.  Suites are defined using the global `describe()` function:
-
-    describe('One suite', function () {
-      it('has a test', function () {
-        ...
-      });
-  
-      it('has another test', function () {
-        ...
-      });
-    });
-
-The Suite name is so that reporting is more descriptive.
-
-Suites are executed in the order in which `describe()` calls are made, usually in the order in which their script files are included.  Additionally, specs within a suite share a functional scope.  So you may declare variables inside a describe block and they are accessible from within your specs.  For example:
-
-    describe('A suite with some variables', function () {
-      var bar = 0
-  
-      it('has a test', function () {
-        bar++;
-        expect(bar).toEqual(1);
-      });
-  
-      it('has another test', function () {
-        bar++;
-        expect(bar).toEqual(2);
-      });
-    });
-
-#### beforeEach
-
-A suite can have a beforeEach declaration. It takes a function that is run before each spec. For example:
-
-    describe('some suite', function () {
-
-      var suiteWideFoo;
-
-      beforeEach(function () {
-        suiteWideFoo = 1;
-      });
-
-      it('should equal bar', function () {
-        expect(suiteWideFoo).toEqual(1);
-      });
-    });
-
-A runner can also have beforeEach declarations. Runner beforeEach functions are executed before every spec in all suites, and execute BEFORE suite beforeEach functions. For example:
-
-    var runnerWideFoo = [];
-
-    beforeEach(function () {
-      runnerWideFoo.push('runner');
-    });
-
-    describe('some suite', function () {
-
-      beforeEach(function () {
-        runnerWideFoo.push('suite');
-      });
-
-      it('should equal bar', function () {
-        expect(runnerWideFoo).toEqual(['runner', 'suite']);
-      });
-    });
-
-#### afterEach
-
-Similarly, there is an afterEach declaration.  It takes a function that is run after each spec. For example:
-
-    describe('some suite', function () {
-
-      var suiteWideFoo;
-      afterEach(function () {
-        suiteWideFoo = 0;
-      });
-
-      it('should equal 1', function () {
-        expect(suiteWideFoo).toEqual(1);
-      });
-
-      it('should equal 0 after', function () {
-        expect(suiteWideFoo).toEqual(0);
-      };
-    });
-
-A runner can also have an afterEach declarations. Runner afterEach functions are executed after every spec in all suites, and execute AFTER suite afterEach functions. For example:
-
-    var runnerWideFoo = [];
-
-    afterEach(function () {
-      runnerWideFoo.push('runner');
-    });
-
-    describe('some suite', function () {
-
-      afterEach(function () {
-        runnerWideFoo.push('suite');
-      });
-
-      it('should be empty', function () {
-        expect(runnerWideFoo).toEqual([]);
-      });
-
-      it('should be populated after', function () {
-        expect(runnerWideFoo).toEqual(['suite', 'runner']);
-      };
-    });
-
-### Single-spec After functions
-
-A spec may ask Jasmine to execute some code after the spec has finished running; the code will run whether the spec finishes successfully or not. Multiple after functions may be given.
-
-    describe('some suite', function () {
-      it(function () {
-        var originalTitle = window.title;
-        this.after(function() { window.title = originalTitle; });
-        MyWindow.setTitle("new value");
-        expect(window.title).toEqual("new value");
-      });
-
-
-### Nested Describes
-Jasmine supports nested describes. An example:
-
-    describe('some suite', function () {
-    
-      var suiteWideFoo;
-    
-      beforeEach(function () {
-        suiteWideFoo = 0;
-      });
-    
-      describe('some nested suite', function() {
-        var nestedSuiteBar;
-        beforeEach(function() {
-          nestedSuiteBar=1;
-        });
-    
-        it('nested expectation', function () {
-          expect(suiteWideFoo).toEqual(0);
-          expect(nestedSuiteBar).toEqual(1);
-        });
-    
-      });
-    
-      it('top-level describe', function () {
-        expect(suiteWideFoo).toEqual(0);
-        expect(nestedSuiteBar).toEqual(undefined);
-      });
-    });
-
-### Spies
-
-Jasmine integrates 'spies' that permit many spying, mocking, and faking behaviors.
-
-Here are a few examples:
-
-    var Klass = function () {
-    };
-
-    var Klass.prototype.method = function (arg) {
-      return arg;
-    };
-
-    var Klass.prototype.methodWithCallback = function (callback) {
-      return callback('foo');
-    };
-
-    ...
-
-    it('should spy on Klass#method') {
-      spyOn(Klass, 'method');
-      Klass.method('foo argument');
-
-      expect(Klass.method).wasCalledWith('foo argument');
-    });
-
-    it('should spy on Klass#methodWithCallback') {
-      var callback = Jasmine.createSpy();
-      Klass.method(callback);
-
-      expect(callback).wasCalledWith('foo');
-    });
-
-
-Spies can be very useful for testing AJAX or other asynchronous behaviors that take callbacks by faking the method firing an async call.
-
-    var Klass = function () {
-    };
-
-    var Klass.prototype.asyncMethod = function (callback) {
-      someAsyncCall(callback);
-    };
-
-    ...
-
-    it('should test async call') {
-      spyOn(Klass, 'asyncMethod');
-      var callback = Jasmine.createSpy();
-
-      Klass.asyncMethod(callback);
-      expect(callback).wasNotCalled();
-
-      var someResponseData = 'foo';
-      Klass.asyncMethod.mostRecentCall.args[0](someResponseData);
-      expect(callback).wasCalledWith(someResponseData);
-
-    });
-
-There are spy-specfic matchers that are very handy.
-
-`expect(x).wasCalled()` passes if `x` is a spy and was called
-
-`expect(x).wasCalledWith(arguments)` passes if `x` is a spy and was called with the specified arguments
-
-`expect(x).wasNotCalled()` passes if `x` is a spy and was not called
-
-`expect(x).wasNotCalledWith(arguments)` passes if `x` is a spy and was not called with the specified arguments
-
-Spies can be trained to respond in a variety of ways when invoked:
-
-`spyOn(x, 'method').andCallThrough()`: spies on AND calls the original function spied on
-
-`spyOn(x, 'method').andReturn(arguments)`: returns passed arguments when spy is called
-
-`spyOn(x, 'method').andThrow(exception)`: throws passed exception when spy is called
-
-`spyOn(x, 'method').andCallFake(function)`: calls passed function when spy is called
-
-Spies have some useful properties:
-
-`callCount`: returns number of times spy was called
-
-`mostRecentCall.args`: returns argument array from last call to spy.
-
-`argsForCall[i]` returns arguments array for call `i` to spy.
-
-Spies are automatically removed after each spec. They may be set in the beforeEach function.
-
-### Disabling Tests & Suites
-
-Specs may be disabled by calling `xit()` instead of `it()`.  Suites may be disabled by calling `xdescribe()` instead of `describe()`.  A simple find/replace in your editor of choice will allow you to run a subset of your specs.
-
-### Asynchronous Specs
-
-You may be thinking, "That's all very nice, but what's this about asynchronous tests?"
-
-Well, say you need to make a call that is asynchronous - an AJAX API, event callback, or some other JavaScript library.  That is, the call returns immediately, yet you want to make expectations 'at some point in the future' after some magic happens in the background.
-
-Jasmine allows you to do this with `runs()` and `waits()` blocks.
-
-`runs()` blocks by themselves simply run as if they were called directly. The following snippets of code should provide similar results:
-
-    it('should be a test', function () {
-      var foo = 0
-      foo++;
-
-      expect(foo).toEqual(1);
-    });
-
-and
-
-    it('should be a test', function () {
-      runs( function () {
-        var foo = 0
-        foo++;
-
-        expect(foo).toEqual(1);
-      });
-    });
-
-multiple `runs()` blocks in a spec will run serially. For example,
-
-    it('should be a test', function () {
-      runs( function () {
-        var foo = 0
-        foo++;
-
-        expect(foo).toEqual(1);
-      });
-      runs( function () {
-        var bar = 0
-        bar++;
-
-        expect(bar).toEqual(1);
-      });
-    });
-
-`runs()` blocks share functional scope -- `this` properties will be common to all blocks, but declared `var`'s will not!
-
-    it('should be a test', function () {
-      runs( function () {
-        this.foo = 0
-        this.foo++;
-        var bar = 0;
-        bar++;
-
-        expect(this.foo).toEqual(1);
-        expect(bar).toEqual(1);
-      });
-      runs( function () {
-        this.foo++;
-        var bar = 0
-        bar++;
-
-        expect(foo).toEqual(2);
-        expect(bar).toEqual(1);
-      });
-    });
-
-`runs()` blocks exist so you can test asynchronous processes. The function `waits()` works with `runs()` to provide a naive
-timeout before the next block is run. You supply a time to wait before the next `runs()` function is executed.  For example:
-
-    it('should be a test', function () {
-      runs(function () {
-        this.foo = 0;
-        var that = this;
-        setTimeout(function () {
-          that.foo++;
-        }, 250);
-      });
-    
-      runs(function () {
-        this.expects(this.foo).toEqual(0);
-      });
-    
-      waits(500);
-    
-      runs(function () {
-        this.expects(this.foo).toEqual(1);
-      });
-    });
-
-What's happening here?
-
-* The first call to `runs()` sets call for 1/4 of a second in the future that increments `this.foo`.
-* The second `runs()` is executed immediately and then verifies that `this.foo` was indeed initialized to zero in the previous `runs()`.
-* Then we wait for half a second.
-* Then the last call to `runs()` expects that `this.foo` was incremented by the `setTimeout`.
-
-## Support
-We now have a Google Group for support & discussion.
-
-* Homepage:  [http://groups.google.com/group/jasmine-js](http://groups.google.com/group/jasmine-js)
-* Group email: [jasmine-js@googlegroups.com](jasmine-js@googlegroups.com)
-* Current build status of Jasmine is visible at [ci.pivotallabs.com](http://ci.pivotallabs.com)
-
-## Maintainers
-
-* [Davis W. Frank](mailto:dwfrank@pivotallabs.com), Pivotal Labs
-* [Rajan Agaskar](mailto:rajan@pivotallabs.com), Pivotal Labs
-* [Christian Williams](mailto:xian@pivotallabs.com), Pivotal Labs
-
-## Acknowledgments
-* A big shout out to the various JavaScript test framework authors, especially TJ for [JSpec](http://github.com/visionmedia/jspec/tree/master) - we played with it a bit before deciding that we really needed to roll our own.
-* Thanks to Pivot [Jessica Miller](http://www.jessicamillerworks.com/) for our fancy pass/fail/pending icons
-* Huge contributions have been made by [Erik Hanson](mailto:erik@pivotallabs.com), [Adam Abrons](mailto:adam@pivotallabs.com) and [Carl Jackson](mailto:carl@pivotallabs.com), and many other Pivots.

README.md

@@ -0,0 +1,64 @@
+<a name="README"><img src="https://raw.githubusercontent.com/jasmine/jasmine/main/images/jasmine-horizontal.svg" width="400px" alt="Jasmine"></a>
+
+# A JavaScript Testing Framework
+
+Jasmine is a Behavior Driven Development testing framework for JavaScript. It does not rely on browsers, DOM, or any JavaScript framework. Thus it's suited for websites, [Node.js](http://nodejs.org) projects, or anywhere that JavaScript can run.
+
+Upgrading from Jasmine 4.x? Check out the [upgrade guide](https://jasmine.github.io/tutorials/upgrading_to_Jasmine_5.0).
+
+## Contributing
+
+Please read the [contributors' guide](https://github.com/jasmine/jasmine/blob/main/.github/CONTRIBUTING.md).
+
+## Installation
+
+There are several different ways to install Jasmine, depending on your 
+environment and how you'd like to use it. See the [Getting Started page](https://jasmine.github.io/pages/getting_started.html)
+for details.
+
+## Usage
+
+See the [documentation site](https://jasmine.github.io/pages/docs_home.html),
+particularly the [Your First Suite tutorial](https://jasmine.github.io/tutorials/your_first_suite)
+for information on writing specs, and [the FAQ](https://jasmine.github.io/pages/faq.html).
+
+## Supported environments
+
+Jasmine tests itself across popular browsers (Safari, Chrome, Firefox, and
+Microsoft Edge) as well as Node.
+
+| Environment       | Supported versions               |
+|-------------------|----------------------------------|
+| Node              | 20, 22, 24                       |
+| Safari            | 26*                              |
+| Chrome            | Evergreen                        |
+| Firefox           | Evergreen, 140                   |
+| Edge              | Evergreen                        |
+
+For evergreen browsers, each version of Jasmine is tested against the version of the browser that is available to us
+at the time of release. Other browsers, as well as older & newer versions of some supported browsers, are likely to work.
+However, Jasmine isn't tested against them and they aren't actively supported. 
+
+\* Supported on a best-effort basis. Support for these versions may be dropped
+if it becomes impractical, and bugs affecting only these versions may not be
+treated as release blockers.
+
+To find out what environments work with a particular Jasmine release, see the [release notes](https://github.com/jasmine/jasmine/tree/main/release_notes).
+
+## Maintainers
+
+* [Gwendolyn Van Hove](mailto:gwen@slackersoft.net)
+* [Steve Gravrock](mailto:sdg@panix.com)
+
+### Maintainers Emeritus
+
+* [Davis W. Frank](mailto:dwfrank@pivotal.io)
+* [Rajan Agaskar](mailto:rajan@pivotal.io)
+* [Greg Cobb](mailto:gcobb@pivotal.io)
+* [Chris Amavisca](mailto:camavisca@pivotal.io)
+* [Christian Williams](mailto:antixian666@gmail.com)
+* Sheel Choksi
+
+Copyright (c) 2008-2019 Pivotal Labs<br>
+Copyright (c) 2008-2026 The Jasmine developers<br>
+This software is licensed under the [MIT License](https://github.com/jasmine/jasmine/blob/main/LICENSE).

RELEASE.md

@@ -0,0 +1,76 @@
+# How to work on a Jasmine Release
+
+## Development
+___Jasmine Core Maintainers Only___
+
+Follow the instructions in `CONTRIBUTING.md` during development.
+
+### Git Rules
+
+Please attempt to keep commits to `main` small, but cohesive. If a feature is contained in a bunch of small commits (e.g., it has several wip commits or small work), please squash them when pushing to `main`.
+
+### Version
+
+We attempt to stick to [Semantic Versioning](http://semver.org/). Most of the time, development should be against a new minor version - fixing bugs and adding new features that are backwards compatible.
+
+The current version lives in the file `/package.json`. This version will be
+copied to `jasmine.js` when the distribution is built. When releasing a new
+version, update `package.json` with the new version and `npm run build` to
+update the gem version number.
+
+Note that Jasmine should only use the "patch" version number if the new release
+contains only bug fixes.
+
+When `jasmine-core` revs its major or minor version, the `jasmine` NPM package
+should also rev to that version.
+
+## Release
+
+When ready to release - specs are all green and the stories are done:
+
+1. Update the release notes in `release_notes` - use the Anchorman gem to 
+   generate the Markdown file and edit accordingly. Include a list of supported
+   environments. Get that information from these places:
+   * For Node, see .circleci/config.yml or the README.
+   * For Firefox ESR and Safari <=17, see scripts/run-sauce-browsers or the README.
+   * For evergreen browsers, trigger a Circle CI run and check the
+     [Saucelabs dashboard](https://app.saucelabs.com/dashboard/tests?ownerId=90a771d55857492da3bd5251a2d92457&ownerType=user&ownerName=jasmine-js&start=last7days)
+     once it's finished.
+   * For Safari >17, trigger the [Safari action](https://github.com/jasmine/jasmine/actions/workflows/safari.yml)
+     and get the version from the output.
+2. Update the version in `package.json`
+3. Run `npm run build`.
+
+### Commit and push core changes
+
+1. Commit release notes and version changes (jasmine.js, package.json)
+2. Push
+3. Tag the release and push the tag.
+4. Wait for Circle CI to go green
+
+### Build standalone distribution
+
+1. Build the standalone distribution with `npm run buildStandaloneDist`
+1. This will generate `dist/jasmine-standalone-<version>.zip`, which you will upload later (see "Finally" below).
+
+### Release the core NPM module
+
+1. `npm login` to save your credentials locally
+2. `npm publish .` to publish what's in `package.json`
+
+### Release the docs
+
+Probably only need to do this when releasing a minor version, and not a patch
+version. See [the README file in the docs repo](https://github.com/jasmine/jasmine.github.io/blob/master/README.md)
+for instructions.
+
+### Release the `jasmine` NPM package
+
+See <https://github.com/jasmine/jasmine-npm/blob/main/RELEASE.md>.
+
+### Publish the GitHub release
+
+1. Visit the releases page and find the tag just published.
+2. Paste in a link to the correct release notes for this release.
+3. If it is a pre-release, mark it as such.
+4. Attach the standalone zipfile.

Rakefile

@@ -1,146 +0,0 @@
-require File.expand_path(File.join(File.dirname(__FILE__), "spec/jasmine_helper.rb"))
-
-def jasmine_sources
-  sources  = ["src/base.js", "src/util.js", "src/Env.js", "src/Reporter.js", "src/Block.js"]
-  sources += Dir.glob('src/*.js').reject{|f| f == 'src/base.js' || sources.include?(f)}.sort
-  sources
-end
-
-def jasmine_filename(version)
-  "jasmine-#{version['major']}.#{version['minor']}.#{version['build']}.js"
-end
-
-def version_hash
-  JSON.parse(File.new("src/version.json").read);
-end
-
-def start_jasmine_server(jasmine_includes = nil)
-  require File.expand_path(File.join(JasmineHelper.jasmine_root, "contrib/ruby/jasmine_spec_builder"))
-
-  puts "your tests are here:"
-  puts "  http://localhost:8888/run.html"
-
-  Jasmine::SimpleServer.start(
-    8888,
-    lambda { JasmineHelper.specs },
-    JasmineHelper.dir_mappings,
-    :jasmine_files => jasmine_includes)
-end
-
-task :default => 'jasmine:dist'
-
-namespace :jasmine do
-
-  desc 'Prepares for distribution'
-  task :dist => ['jasmine:build', 'jasmine:doc']
-
-  desc 'Check jasmine sources for coding problems'
-  task :lint do
-    passed = true
-    jasmine_sources.each do |src|
-      lines = File.read(src).split(/\n/)
-      lines.each_index do |i|
-        line = lines[i]
-        undefineds = line.scan(/.?undefined/)
-        if undefineds.include?(" undefined") || undefineds.include?("\tundefined")
-          puts "Dangerous undefined at #{src}:#{i}:\n > #{line}"
-          passed = false
-        end
-      end
-    end
-
-    unless passed
-      puts "Lint failed!"
-      exit 1
-    end
-  end
-
-  desc 'Builds lib/jasmine from source'
-  task :build => :lint do
-    puts 'Building Jasmine from source'
-    require 'json'
-
-    sources = jasmine_sources
-    version = version_hash
-
-    old_jasmine_files = Dir.glob('lib/jasmine*.js')
-    old_jasmine_files.each do |file|
-      File.delete(file)
-    end
-
-    jasmine = File.new("lib/#{jasmine_filename version}", 'w')
-
-    sources.each do |source_filename|
-      jasmine.puts(File.read(source_filename))
-    end
-
-    jasmine.puts %{
-jasmine.version_= {
-  "major": #{version['major']},
-  "minor": #{version['minor']},
-  "build": #{version['build']},
-  "revision": #{Time.now.to_i}
-  };
-}
-
-    jasmine.close
-  end
-
-  desc "Build jasmine documentation"
-  task :doc do
-    puts 'Creating Jasmine Documentation'
-    require 'rubygems'
-    #sudo gem install ragaskar-jsdoc_helper
-    require 'jsdoc_helper'
-
-
-    JsdocHelper::Rake::Task.new(:lambda_jsdoc) do |t|
-      t[:files] = jasmine_sources << 'lib/TrivialReporter.js'
-      t[:options] = "-a"
-    end
-    Rake::Task[:lambda_jsdoc].invoke
-  end
-
-
-  task :server do
-    files = jasmine_sources + ['lib/TrivialReporter.js', 'lib/consolex.js']
-    jasmine_includes = lambda {
-      raw_jasmine_includes = files.collect { |f| File.expand_path(File.join(JasmineHelper.jasmine_root, f)) }
-      Jasmine.cachebust(raw_jasmine_includes).collect {|f| f.sub(JasmineHelper.jasmine_src_dir, "/src").sub(JasmineHelper.jasmine_lib_dir, "/lib") }
-    }
-    start_jasmine_server(jasmine_includes)
-  end
-
-  task :server_build => 'jasmine:build' do
-
-    start_jasmine_server
-  end
-
-  namespace :test do
-    task :ci => :'ci:local'
-    namespace :ci do
-
-      task :local => 'jasmine:build' do
-        require "spec"
-        require 'spec/rake/spectask'
-        Spec::Rake::SpecTask.new(:lambda_ci) do |t|
-          t.spec_opts = ["--color", "--format", "specdoc"]
-          t.spec_files = ["spec/jasmine_spec.rb"]
-        end
-        Rake::Task[:lambda_ci].invoke
-      end
-
-      task :saucelabs => ['jasmine:copy_saucelabs_config', 'jasmine:build'] do
-        ENV['SAUCELABS'] = 'true'
-        Rake::Task['jasmine:test:ci:local'].invoke
-      end
-    end
-  end
-
-  desc 'Copy saucelabs.yml to work directory'
-  task 'copy_saucelabs_config' do
-    FileUtils.cp '../saucelabs.yml', 'spec'
-  end
-end
-
-task :jasmine => ['jasmine:server']

artist-website/.gitignore

@@ -0,0 +1,28 @@
+# Logs
+logs
+*.log
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+pnpm-debug.log*
+lerna-debug.log*
+
+node_modules
+dist
+dist-ssr
+*.local
+
+# tauri
+/src-tauri/target
+/src-tauri/Cargo.lock
+
+# Editor directories and files
+.vscode/*
+!.vscode/extensions.json
+.idea
+.DS_Store
+*.suo
+*.ntvs*
+*.njsproj
+*.sln
+*.sw?

artist-website/index.html

@@ -0,0 +1,13 @@
+<!doctype html>
+<html lang="zh-CN">
+  <head>
+    <meta charset="UTF-8" />
+    <link rel="icon" type="image/svg+xml" href="/vite.svg" />
+    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
+    <title>藝術家作品集</title>
+  </head>
+  <body>
+    <div id="app"></div>
+    <script type="module" src="/src/main.ts"></script>
+  </body>
+</html>

artist-website/package.json

@@ -0,0 +1,20 @@
+{
+  "name": "artist-website",
+  "version": "1.0.0",
+  "type": "module",
+  "scripts": {
+    "dev": "vite",
+    "build": "vite build",
+    "preview": "vite preview",
+    "tauri": "tauri"
+  },
+  "dependencies": {
+    "vue": "^3.4.0"
+  },
+  "devDependencies": {
+    "@tauri-apps/api": "^1.5.0",
+    "@tauri-apps/cli": "^1.5.0",
+    "@vitejs/plugin-vue": "^5.0.0",
+    "vite": "^5.0.0"
+  }
+}