Static analysis of `exportPattern()` directives

Open
#8,520 9 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
30/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
r
Domain
devtools

Research direction

Start with the existing DESCRIPTION and NAMESPACE export analysis described in #1325 and pull request #870, then review dependency-source access in #2286. The work is complete when source parsing identifies top-level assignments, packages can declare dynamic symbols, and exportPattern() is applied to known namespace objects.

Written by the indexing model from the issue text.

Description

area: diagnostics lang: r

Follow-up to #1325 and https://github.com/posit-dev/ark/pull/870.

We now examine the DESCRIPTION and NAMESPACE files of a package to statically determine its exports, but we don't support the exportPattern() NAMESPACE directive yet, which exports all symbols matching a regex.

It's tricky because packages are installed without their source code, which means we can't statically discover what objects are defined in a namespace. To do this, we'll need access to the source code of the project dependencies: #2286. Then we'll be able to:

  • Parse the source code and detect all top-level assignments

  • For dynamic assignments, packages will have to declare the symbols:

    # Declaration
foo <- function(my, signature) {}

.onLoad <- function(...) {
  # Dynamic definition. This case is analysable in principle but the namespace
  # might be modified in more complex ways, e.g. via `.Call()`, hence the need
  # for declarations in general
  foo <<- function(my, signature) body
}

  • Apply export pattern to known namespace objects

Dominant language
TypeScript
Stars
4.3k
Forks
184
Avg merge
1d 9h
Merged PRs (30d)
195

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from posit-dev/positron

All issues in posit-dev/positron

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.